Choisissez l'effort de conception de code ou la paresse dans le monde de la Banque

Je travaille depuis deux ans dans une grande banque d'investissement.

J'ai réalisé quelques projets techniques avec le désir de créer le code le plus optimisé, en respectant les bons schémas de conception adaptés, le principe SOLIDE, la loi de déméter et en évitant toutes sortes de codes en double ...

Lorsque la livraison en production => zéro bogue, tout s'est passé comme prévu.

Mais, une majorité de développeurs sont venus me voir afin de préciser que tout mon code est trop complexe pour la compréhension en lecture. J'ai écouté par exemple: "faites des if et instanceof, oubliez le polymorphisme pour qu'il soit très facile de corriger les bugs de production d'urgence". Je n'ai pas préféré répondre ......

Sachant que ces développeurs ne sont pas du tout curieux, refusant les efforts pour comprendre une bonne conception (par exemple, 90% des développeurs ne savent pas ce qu'est un modèle de stratégie et font du code procédural et jamais oo-design parce qu'ils veulent, disent-ils, la simplicité ), mes chefs de projet m'ont dit que je suis vraiment dans le mauvais sens et trop idéaliste pour le monde de la Banque.

Que me conseillez-vous? Devrais-je garder le désir de vraiment bon code ou m'adapter à la majorité des développeurs qui sont, je le répète, vraiment pas intéressants par le code de conception qui est selon moi, toute la beauté de notre travail de développeur.

Ou au contraire, doivent-ils apprendre les principes de base OO et les meilleures pratiques pour s'adapter à mon code?

mes chefs de projet m'ont dit que je suis vraiment dans le mauvais sens et trop idéaliste pour le monde de la Banque.

GTFO!

Il est temps de partir et de les plaindre. Pourquoi devriez-vous vous en foutre? Vous savez que cela leur coûtera de l'argent à long terme avec leur personnel incompétent. Ce n'est pas un jeu de discussion technique. Il s'agit de politique. Demandez-leur de former les autres développeurs ou GTFO! Si vous n'avez pas assez de poids politique, alors GTFO! Recherchez une entreprise avec de meilleures pratiques.

La seule raison de rester là-bas est une compensation adéquate pour vos maux de tête. Alors ils feraient mieux de payer bien au-dessus de la moyenne ou du GTFO! Je doute que vous puissiez également vous développer en tant que développeur de logiciels. La croissance de notre profession est principalement réalisée en travaillant avec des personnes qui sont meilleures que vous et qui encouragent les meilleures pratiques. Et mieux vous vous portez, plus votre valeur marchande est élevée pour les entreprises qui s'en soucient.

Oui, je sais que ce n'est pas une de mes réponses habituelles mais vraiment, si vous ne pouvez pas jouer au jeu politique dans cette entreprise, GTFO.

Que me conseillez-vous? Devrais-je garder le désir de vraiment bon code ou m'adapter à la majorité des développeurs qui sont, je le répète, vraiment pas intéressants par le code de conception qui est selon moi, toute la beauté de notre travail de développeur.

Je ne travaillerais pas pour une entreprise qui souhaite que je fournisse des solutions sous-optimales. Je veux graver mon nom dans le logiciel. Je veux en être fier. Je n'écris pas d'applications procédurales dans des langages basés sur le paradigme OO. Je crois en un logiciel de haute qualité et si l'entreprise ne le fait pas, je vais GTFO! J'espère que vous en avez assez "va te faire foutre de l'argent".

Endroit difficile. Je pense que vous pouvez aller de deux façons en parallèle, en tenant bon et en faisant preuve de volonté de compromis:

• C'est une question d'argent. Comme tout travail de développement en fait, mais comme vous mettez l'accent sur l'environnement bancaire, cela devrait fonctionner encore mieux;). Montrez-leur que votre style permet d'économiser de l'argent. Trouvez un exemple de la façon dont une modification des exigences pourrait être effectuée très facilement en raison de votre conception. Essayez de trouver un morceau d'un autre code (vous devez vous assurer de ne pas être trop agressif ici, mais bon, il s'agit de comparer des styles de code) qui est susceptible de se casser bientôt, et montrez-leur comment vous n'avez pas à le faire se soucier de ces problèmes parce que votre code est de meilleure qualité pour commencer.

• C'est une question d'argent. Et si votre style de codage coûte de l'argent? Cela peut très bien faire, si d'autres personnes passent plus de temps à essayer de comprendre votre code que ce qui est enregistré par une conception appropriée. Vous faites peut-être la bonne chose techniquement et ne contribuez toujours pas positivement à l'effort d'équipe. En outre, il est possible d'exagérer la conception de la POO. Je suis avec vous du côté "un bon design, c'est beau", mais j'essaie de vous faire prendre conscience ici de leur point de vue et de la façon dont ils peuvent réellement être justes de leur point de vue. Parallèlement au point précédent, essayez de trouver un endroit où vous en avez fait trop. Cela vous donne une certaine marge de manœuvre: vous pouvez dire, ok, je peux être un peu plus pragmatique ici et là, mais regardez, il y a aussi des endroits où ce code est vraiment meilleur.

Mais, une majorité de développeurs sont venus me voir afin de préciser que tout mon code est trop complexe pour la compréhension en lecture

Vous est-il venu à l'esprit qu'ils avaient peut-être raison?

J'ai travaillé avec quelqu'un qui a mis beaucoup d'efforts pour écrire du code qu'il a décrit comme élégant. Il a passé beaucoup de temps à dénoncer le travail des autres comme n'étant pas élégant. Lorsqu'il s'agit de maintenir le code, son code n'est pas celui que je choisirais de modifier. Il est si précis et exigeant que le changer est profondément chargé de danger.

Le mot intéressant que vous mentionnez ici est "complexe". Un code qui peut être décrit comme complexe peut rarement être également décrit comme particulièrement bon.

Les fabricants de meubles de l'époque victorienne (du moins ceux dont nous voyons encore le travail aujourd'hui) étaient de véritables artisans, ce qu'ils fabriquaient était fonctionnel, beau, bien conçu et conçu et construit pour durer toute une vie. Cependant, au cours des 150 dernières années, le monde a changé. Peu de gens sont prêts à payer pour un tel savoir-faire, lorsque des alternatives moins chères sont plus pragmatiques commercialement lors de l'achat d'une table de salle à manger.

De nombreux programmeurs veulent être les artisans d'autrefois, malheureusement, le commerce exige que cela ne se produise pas tout le temps. Vous avez le choix, vous adaptez ou partez. Il y a des entreprises qui veulent des artisans, mais elles sont massivement plus nombreuses que celles qui veulent des produits qui fonctionnent surtout, bon marché et maintenant.

L'indice pour moi que vous n'êtes pas adapté à la plupart des développements de logiciels commerciaux est le "Lorsque la livraison en production => zéro bogue". Même la Nasa n'y est pas parvenue avec les navettes spatiales.

Les seuls endroits où votre attention aux détails, et donc le coût initial, sont susceptibles d'être acceptables sont les systèmes vitaux de niveau 1 - par exemple, avionique / aérospatiale, automobile, militaire et médical.

Le problème est que vous travaillez au mauvais endroit. On dirait que vous êtes un programmeur très académique. Vous ne réussirez pas bien dans l'environnement dans lequel vous vous trouvez et il est fort probable qu'une excuse soit inventée pour se débarrasser de vous et de votre code "trop ​​complexe". Vous pouvez recevoir des affectations indésirables et / ou des évaluations de performances médiocres et ainsi de suite jusqu'à ce que vous partiez de votre propre chef ou qu'ils aient une trace papier suffisante pour vous licencier.

Je vous recommande de trouver un lieu de travail qui valorisera vos tendances académiques. Ils sont là-bas. Vous en trouverez également sur la frontière entre pragmatique et académique. Un travail comme celui-ci peut être votre meilleure option car cela vous permettrait d'inviter du chaos dans votre approche tout en aidant les autres à maîtriser la leur.

Avant de prendre des mesures aussi radicales que de changer d'employeur, j'essaierais d'améliorer votre propre capacité d'expliquer aux non-programmeurs comme vous les cadres supérieurs pourquoi votre façon de coder est meilleure pour l'entreprise et de leur faire gagner du temps et de l'argent. Et aussi, assurez-vous que vous n'avez pas appliqué de modèles de conception uniquement pour des motifs de conception - êtes-vous sûr que vous avez également suivi les règles de KISS et YAGNI? (D'accord, le modèle de stratégie et le polymorphisme ne sont pas sorciers, donnez à vos collègues le temps de s'adapter et d'expliquer pourquoi vous choisissez cette approche.)

Dans mon entreprise, nous avons organisé une série d'ateliers basés sur Clean Code Developer . Le but était de créer un forum en dehors des activités quotidiennes normales avec ses délais trépidants et ses compromis fâcheux, où les développeurs pourraient se renseigner sur les principes de conception de logiciels (comme vous l'avez mentionné), les techniques de programmation, etc. et réfléchir sur leurs projets et leur propre travail.

Des exemples réels de projets réels ont également été discutés. Les retours des participants ont été très positifs pour l'AFAIK. Il est cependant difficile de mesurer un avantage réel.

La participation à ces ateliers était en partie sur le temps parrainé par l'entreprise, en partie sur le temps libre des participants. Vous n'atteindrez pas ces collègues qui ne se soucient pas d'apprendre et qui veulent simplement faire leur travail et rentrer chez eux, mais pour quiconque ayant un intérêt pour son propre travail, cela pourrait être intéressant.

Je voudrais tout d'abord vérifier que votre chemin est vraiment meilleur. Le code orienté objet peut être très agréable, mais il peut aussi être un cauchemar d'effets secondaires cachés et chaque action peut nécessiter plusieurs classes différentes.

Mieux encore, allez à InfoQ et regardez la conférence de Rich Hickey sur "Simple Made Easy"

Vous allez devoir céder un peu si vous voulez continuer à y travailler sans difficultés constantes. Un groupe de développeurs entièrement procédural n'acceptera pas immédiatement le polymorphisme. Bien qu'ils ne puissent pas concevoir de manière OO, ils peuvent apprendre de votre code. Ils peuvent apprécier que certains d'entre vous soient plus faciles à gérer.

En remarque, vous devez poser des questions pendant le processus d'entrevue pour voir quel processus de développement et méthodologie de codage est utilisé si vous pensez qu'il est important de correspondre à vos préférences.

Des urgences se produisent. Vous n'êtes pas parfait et leurs mains se gâcher votre code à un moment donné. À moins que vous ne preniez jamais de congé, ce qui, comme le confirmera votre médecin, n'est pas bon pour votre santé. Et conduit à des chances plus élevées d'émettre un mauvais code.

Votre code peut avoir une qualité supérieure (fait non prouvé), mais ils ont des politiques . (comme un fait infernal)

Vous avez été averti de suivre les politiques et serez responsable de ne pas les avoir suivies. En situation d'urgence. Dans une application bancaire. Je veux dire, si votre objectif est de finir pauvre et en prison, je peux trouver de nombreuses façons plus amusantes et plus significatives d'obtenir le même résultat.

Vos camarades de cellule, cependant, seraient ravis de vous entendre divaguer sur le manque de curiosité de vos anciens collègues.

(là encore, votre entreprise n'a probablement pas de politiques internes contre la conception OO, mais l'ingénieur maladroit et formé à COBOL qui tentera de réparer votre code en inventera un peu et, à mon humble avis, dans le pire des cas, il '' ll a 40% de chances de marquer un coup critique)

Essayez de vous rappeler que la programmation est considérée par certains comme un moyen de parvenir à une fin plutôt que pour elle-même. Pensez à tous les produits et services que vous utilisez: passez-vous beaucoup de temps à déterminer si le code ci-dessous est fait avec élégance? Ou les appréciez-vous simplement car ils fonctionnent? Trouvez une industrie ou une cause qui vous passionne, puis trouvez une organisation avec cela, puis offrez-leur des solutions qui incluent la programmation, mais pas seulement. Les problèmes peuvent être résolus avec brio de différentes manières.