Comment les programmeurs rapides et sales savent-ils qu'ils ont bien compris?

Si vous demandez aux programmeurs pourquoi ils devraient écrire du code en clair, la première réponse que vous obtiendrez est la maintenabilité. Bien que cela soit sur ma liste, ma raison principale est plus immédiate et moins altruiste: je ne peux pas dire si mon nouveau code est correct s'il est trop sale. Je constate que je me suis tellement concentré sur des fonctions individuelles et des lignes de code que lorsque je termine mon premier brouillon et que je recule pour regarder la situation dans son ensemble, cela ne correspond parfois pas parfaitement. Consacrer une heure ou deux au refactoring pour la propreté révèle souvent des erreurs de copier / coller ou des conditions aux limites très difficiles à détecter dans le brouillon.

Cependant, certaines personnes pensent qu'il est parfois acceptable de vérifier intentionnellement du code sale dans l'intérêt des logiciels fournis, avec un plan de "nettoyage plus tard". Existe-t-il une technique réalisable qui leur donne confiance dans l'exactitude de leur code lorsque la lisibilité est loin d'être idéale? Est-ce une compétence qui vaut la peine d'être développée? Ou bien est-ce que certaines personnes trouvent plus facile d'accepter un manque de confiance dans le code?

Le code n'est probablement pas correct.

Cependant, cela peut ne pas avoir d'importance.

Rapide et sale peut être la bonne voie à suivre dans les situations où:

• Le code a une courte durée de vie . Par exemple, vous transformez un tas de données en un format standard avec un programme ad-hoc.
• L'impact négatif de l'échec est faible :
  • Les données que vous transformez sont non critiques et les erreurs peuvent être facilement corrigées.
  • L'utilisateur final est un programmeur sympathique, qui discutera des messages d'erreur et les contournera, par exemple, en massant l'entrée.

Parfois, il n’est pas important que le code soit robuste et gère toutes les entrées imaginables. Parfois, il suffit de gérer les données connues que vous avez sous la main.

Dans cette situation, si les tests unitaires vous aident à écrire le code plus rapidement (c'est le cas pour moi), utilisez-les. Sinon, code rapide et sale, faites le travail. Les insectes qui ne se déclenchent pas importent peu. Les bugs que vous corrigez ou contournez à la volée importent peu.

Ce qui est absolument essentiel, c’est de ne pas mal diagnostiquer ces situations. Si vous codez rapidement parce que le code ne sera utilisé qu'une seule fois, alors quelqu'un décide de le réutiliser dans un projet qui mérite un meilleur code, ce code méritait plus d'attention.

Ils ne le font pas. Je travaille actuellement sur une base de code créée par des programmeurs "rapides et sales" qui "le nettoyeraient plus tard". Ils sont partis depuis longtemps, et le code vit toujours, craignant son chemin vers l'oubli. Les codeurs Cowboy , en général, ne comprennent tout simplement pas tous les modes de défaillance potentiels de leurs logiciels et ne comprennent pas les risques auxquels ils exposent la société (et les clients).

D'accord, au risque d'être un appât complet, je vais "défendre les démons" du point de vue opposé.

Je propose que nous, les développeurs, ayons tendance à nous préoccuper excessivement de choses telles que les bonnes pratiques et la propreté du code. Je suggère que, même si ces choses sont importantes, rien n’importe si vous n’exportez jamais .

Quiconque a été dans cette entreprise pendant un certain temps serait probablement d’accord pour dire qu’il serait possible de jouer avec un logiciel plus ou moins indéfiniment. Duc Nukem Forever, mes amis. Il arrive un moment où cette fonctionnalité intéressante ou ce travail de refactorisation si urgent devrait être mis de côté et la chose appelée DONE.

J'ai souvent combattu mes collègues à ce sujet. Il y a TOUJOURS un dernier ajustement, quelque chose d'autre qui "devrait" être fait pour que ce soit "correct". Vous pouvez toujours trouver cela. À un moment donné, dans le monde réel, assez bon doit juste être assez bon. Aucun logiciel d'expédition réel ou actuel n'est parfait. Aucun. Au mieux, ça suffit.

Ces programmeurs ne savent presque jamais qu'ils ont bien compris, ils ne le croient pas. Et la différence peut ne pas être facile à percevoir.

Je me souviens comment j'avais l'habitude de programmer avant d'avoir appris les tests unitaires. Et je me souviens de ce sentiment de confiance à un niveau totalement différent après avoir exécuté ma première suite décente de tests unitaires. Je n'avais jamais connu un tel niveau de confiance dans mon code.

Pour quelqu'un qui manque de cette expérience, il est impossible d'expliquer la différence. Ainsi, ils peuvent même continuer à se développer en mode code-et-prier tout au long de leur vie, en croyant avec bienveillance (et par ignorance) qu’ils font de leur mieux compte tenu des circonstances.

Cela dit, il peut en effet y avoir de grands programmeurs et des cas exceptionnels, quand on parvient vraiment à garder tout l’espace du problème dans son esprit, dans un état de fluidité totale. J'ai vécu des moments rares comme celui-ci, lorsque je savais parfaitement quoi écrire, le code venait de voler de moi sans effort, je pouvais prévoir tous les cas spéciaux et toutes les conditions limites, et le code résultant fonctionnait à merveille . Je ne doute pas qu'il existe des génies de la programmation capables de rester dans un tel état de flux pendant de longues périodes ou même la plupart du temps, et ce qu'ils produisent est un code magnifique, apparemment sans effort. J'imagine que de telles personnes pourraient ne pas ressentir le besoin d'écrire de petits tests unitaires pour vérifier ce qu'elles savent déjà. Et si vous êtes vraiment un génie, tout ira bien (même si, même dans ce cas, vous ne serez pas au courant de ce projet et vous devriez penser à vos successeurs ...). Mais sinon ...

Et avouons-le, il y a des chances pour que vous ne l'êtes pas. Pour ma part, je sais que je ne le suis pas. J'ai eu quelques rares moments de flux - et d'innombrables heures de chagrin et de chagrin, généralement causés par mes propres erreurs. Il vaut mieux être honnête et réaliste. En fait, je pense que les plus grands programmeurs sont pleinement conscients de leur propre faillibilité et de leurs erreurs passées. Ils ont donc consciemment pris l’habitude de vérifier leurs hypothèses et de rédiger ces petits tests unitaires afin de rester prudents. ( "Je ne suis pas un bon programmeur - juste un bon programmeur avec de bonnes habitudes." - Kent Beck.)

Tests unitaires . C'est le seul moyen de faire confiance à un code (sale ou non).

Sur une note de côté;

les raccourcis font les longs retards (Pippin)

Il est bon d'apprendre à accepter qu'aucun système logiciel d'une complexité raisonnable ne sera parfait, quel que soit le nombre de tests unitaires et d'ajustements de code effectués. Un certain degré de chaos et de vulnérabilité face à l'inattendu sera toujours caché dans le code. Cela ne signifie pas qu'il ne faut pas essayer de produire un code correct ni de faire des tests unitaires. Ce sont, bien sûr, importants. Il faut rechercher un équilibre qui variera d’un projet à l’autre.

La compétence à développer consiste à comprendre quel niveau de «perfection» doit être utilisé pour un projet particulier. Par exemple, si vous écrivez une application de dossiers médicaux électroniques avec un calendrier de projet de 12 mois, vous voudrez consacrer beaucoup plus de temps à la vérification et à la maintenance de votre code, contrairement à une application Web d'enregistrement de conférence unique. cela doit être déployé d'ici vendredi. Les problèmes surviennent lorsque quelqu'un qui utilise l'application DME devient bâclé ou que l'application d'enregistrement n'est pas déployée à temps car le programmeur est trop occupé à modifier le code.

Rapide et sale convient parfaitement dans un sous-système . Si vous avez une interface bien définie entre votre merde et le reste du système, et un bon ensemble de tests unitaires qui vérifient que votre code vilain et sale est correct, tout ira bien.

Par exemple, vous avez peut-être un bidouillage hideux d'expressions régulières et de décalages d'octets pour analyser certains fichiers provenant d'une tierce partie. Et supposons que vous avez un test indiquant que le résultat obtenu lors de l'analyse des exemples de fichiers correspond à vos attentes. Vous pourriez nettoyer cela pour pouvoir ... Je ne sais pas, réagir plus rapidement lorsqu'un tiers modifie un format de fichier? Cela n'arrive pas assez souvent. Plus vraisemblablement, ils changeront pour une toute nouvelle API et vous jetterez l'ancien analyseur pour en ajouter un nouveau conforme à la même API, et voilà, vous avez terminé.

Là où rapide et sale devient un problème, c'est lorsque votre architecture est rapide et sale. Votre objet de domaine principal doit être bien pensé, ainsi que vos interfaces, mais les bords de votre système peuvent généralement être désordonnés sans avoir à payer le traqueur.

Voici une histoire sur un programmeur rapide et sale que je connais.

J'ai connu une personne qui considère les tests unitaires comme une perte de temps. Après de nombreuses discussions, il en a finalement écrit un. Elle consistait en une longue méthode saupoudrée de && et || et retourné un booléen pour affirmer vrai. La déclaration couvre 20 lignes. Là encore, il a écrit une classe dans laquelle chaque méthode comportait une ligne et la principale, plus de 1000 lignes sans espace. C'était un mur de texte. Quand j'ai revu son code et inséré de nouvelles lignes, il m'a demandé «pourquoi». J'ai dit 'à cause de la lisibilité'. Il soupira et les supprima. Il a mis un commentaire en haut "Ne le touche pas, ça marche!"

La dernière fois que je lui ai parlé, il a codé un site Web pour une entreprise. Il essayait de trouver un bug. Il avait passé les 3 derniers jours à le faire 8 heures par jour. Un peu plus tard, je lui ai reparlé et il s'est avéré que son coéquipier a changé la valeur d'un littéral et ne l'a pas mise à jour ailleurs. Ce n'était pas une constante. Alors, il a aussi changé les autres littéraux pour que son bug soit corrigé. Il s'est plaint du code spaghetti de son coéquipier. Il m'a dit 'Haha, ne savons-nous pas tous ce que c'est que de rester éveillé toute la nuit avec le débogueur sans dormir un seul virus? "Il pense que c'est quelque chose de très bien fait par les programmeurs et qu'il se sent vraiment bien.

En outre, il pense que lire des livres de programmation et des blogs est inutile. Il dit: «commence juste à programmer». Cela fait 12 ans qu'il le fait et il pense être un excellent programmeur. / facepalm

En voici d'autres.

Une autre fois, nous écrivions une classe DatabaseManager pour notre application Web. Il a mis tous les appels de base de données dedans. C'était une classe de Dieu avec plus de 50 méthodes pour chaque chose imaginable. J'ai suggéré de le scinder en sous-classes, car tous les contrôleurs n'ont pas besoin de connaître chaque méthode de base de données. Il n'était pas d'accord, car il était «facile» de n'avoir qu'un seul cours pour toute la base de données et d'ajouter «rapidement» une nouvelle méthode chaque fois que nous en avions besoin. Au final, DatabaseManager avait plus de 100 méthodes publiques allant de l'authentification de l'utilisateur au tri des emplacements de sites archéologiques.

Ma leçon en évitant rapide et sale était quand j'avais six mois pour livrer ce qui était estimé (sous-estimé) pour une année de travail. J'ai décidé de rechercher des méthodologies avant de commencer le travail. Finalement, j'ai investi trois mois de recherche et j'ai été en mesure de livrer les trois mois restants.

Nous avons eu beaucoup à gagner en identifiant les fonctionnalités communes et en construisant les bibliothèques requises pour répondre à ces besoins. Je vois encore des codeurs écrire leur propre code quand il y a des routines de bibliothèque disponibles. Souvent, ces codeurs réécrivent, ou au mieux, copient et collent, le même code lorsqu'ils ont besoin de résoudre le même problème ultérieurement. Les corrections de bogues ne capturent invariablement que certaines des copies de code.

Un développeur a donné une réponse éloquente lorsque je lui ai demandé d'utiliser le code de bibliothèque: "N'est-ce pas tromper? Je devais écrire tout mon code à l'école."

Dans certains cas, j’imagine qu’il pourrait exister une grande série de tests de régression permettant de détecter "tous" les bogues et de vérifier le comportement, permettant ainsi une technique de codage rapide et sale. Mais il s’agit surtout d’une mauvaise planification de projet et d’un responsable qui pense que c’est plus important de le faire que de le faire correctement.

Et oubliez "nettoyez-le plus tard", cela n'arrive jamais. Dans de rares cas, le programmeur aura oublié la plus grande partie du code, rendant le travail beaucoup plus coûteux que s'il l'avait fait correctement la première fois.

Le produit est expédié.

Le code n'existe pas en vase clos. J'ai subi des souffrances indicibles en luttant contre les conséquences d'un codage rapide et sale et d'un cow-boy. Mais parfois, la priorité est de finir le produit, sans chercher à écrire le meilleur code. En fin de compte, si le produit est expédié et fonctionne suffisamment bien, les utilisateurs et les clients ne sauront pas ou ne s'inquièteront pas de la "mauvaise" qualité du code qu'il contient. droit "tant que je l'ai sorti de la porte.

Oui, cela dans un problème d'organisation et "ne devrait jamais se produire." Cependant, si vous écrivez du code dans une organisation mal gérée et dont le délai de traitement est très long, les options sont limitées au niveau du programmeur.

Je ne pense pas qu'ils puissent dire honnêtement qu'ils ont bien fait les choses si ce n'est pas facile à maintenir. S'ils admettent qu'ils doivent «nettoyer plus tard», il y a probablement quelque chose qu'ils n'ont pas suffisamment réfléchi. Le tester à fond ne fera que révéler véritablement tout problème lié à un code sale.

Personnellement, je n’aurais pas pour objectif de développer les compétences nécessaires pour «écrire du code sale» et d’avoir confiance en son exactitude. Je préférerais écrire le code approprié la première fois.

Comment savent-ils qu'ils ont bien compris? Le test est la réponse simple.

Si leur code a été testé minutieusement par une bonne équipe d’assurance qualité et qu’il est adopté, je dirais qu’ils ont bien compris.

Écrire du code rapide et sale n’est pas une habitude, mais vous pouvez passer 20 minutes à écrire du code pouvant être classé comme sale ou 4 heures à refactoriser beaucoup de code pour le faire correctement. Dans le monde des affaires, il ne reste parfois que 20 minutes pour faire le travail. Lorsque les délais sont serrés, il peut s’avérer l’unique option.

J'ai moi-même été sur les deux bouts, j'ai dû corriger le code sale et écrire le mien afin de contourner les limites d'un système dans lequel je développais. Je dirais que j'avais confiance dans le code I a écrit parce que même s’il était sale et qu’il s’agissait d’un peu de piratage, j’ai parfois veillé à ce qu’il soit minutieusement testé et doté d’un système de traitement des erreurs intégré; ainsi, en cas de problème, il ne détruirait pas le reste du système.

Lorsque nous méprisons ces programmeurs rapides et sales, nous devons nous rappeler une chose: un client ne paie généralement pas avant d'avoir le produit, s'il est expédié et qu'il passe dans les tests UAT et trouve les bogues dans le code rapide et sale, il s'agit d'un Ils sont moins susceptibles de se retirer lorsqu'ils ont devant eux un produit presque opérationnel, mais s'ils n'ont rien et que vous leur dites "vous l'aurez bientôt, nous ne faisons que réparer x" ou "cela a été retardé car nous devions obtenir y travaillant à la perfection, ils sont plus enclins à abandonner et à aller avec un concurrent.

Bien sûr, comme cette image le démontre, personne ne devrait sous-estimer le danger d'un code rapide et sale!

Je ne pense pas que vous devriez même commencer à suivre cette voie. Rapide et sale peut vous donner l'avantage temporel d'une finition plus rapide, mais vous payez toujours dix fois plus pour le faire à la fin.

A mon avis, apprendre à juger de l'exactitude du code Q & D n'est pas une compétence à développer, c'est simplement une mauvaise pratique. Voici pourquoi:

Je ne pense pas que "rapide et sale" et "meilleure pratique" vont de pair. De nombreux codeurs (moi-même inclus) ont créé du code rapide et sale en raison d'un biais dans les triples contraintes . Lorsque je devais le faire, cela résultait généralement d'un glissement de la portée associé à une échéance de plus en plus proche. Je savais que le code que je vérifiais était nul, mais il créait des sorties appropriées avec un ensemble d'entrées. Très important pour nos parties prenantes, nous avons expédié à temps.

Un coup d'œil au rapport original de CHAOS montre assez clairement que Q & D n'est pas une bonne idée et va tuer le budget plus tard (que ce soit en maintenance ou en expansion). Apprendre à juger si le code Q & D est correct est une perte de temps. Comme l'a dit Peter Drucker, "rien n'est plus inutile que de faire efficacement ce qu'il ne faut pas faire du tout."

Je ne peux pas dire si mon nouveau code est correct s'il est trop sale.

"Sale" signifie différentes choses pour différentes personnes. Pour moi, cela signifie surtout de compter sur des choses sur lesquelles vous savez que vous ne devriez probablement pas compter, mais sur lesquelles vous savez également que vous pouvez vous attendre à travailler à court terme. Exemples: en supposant qu'un bouton mesure 20 pixels de haut au lieu de calculer la hauteur; coder en dur une adresse IP au lieu de résoudre un nom; compter sur un tableau à trier car vous savez que c’est le cas, même si la méthode qui fournit le tableau ne le garantit pas.

Le code sale est fragile - vous pouvez le tester et savoir qu'il fonctionne maintenant , mais il y a fort à parier qu'il se cassera dans le futur (ou obligerait tout le monde à marcher sur des œufs par peur de le briser).

Au risque de paraître un peu controversé, je dirais que personne ne SAIT que leur code est correct à 100% et à 100% sans erreur. Même lorsque vous avez une très bonne couverture de test et que vous appliquez de manière rigoureuse les bonnes pratiques BDD / TDD, vous pouvez toujours développer un code contenant des erreurs, et oui même pouvant contenir des effets secondaires!

Le fait d'écrire du code et de le supposer fonctionne suppose un excès de confiance de la part du développeur qui comprend ses propres capacités. Lorsque des problèmes surviendront (ce qui sera inévitablement le cas), l'effort de débogage et de maintenance du code sera coûteux, en particulier si un autre développeur en a besoin. pour maintenir le code plus tard. La vraie différence réside dans l'application de bonnes pratiques en matière d'ingénierie logicielle, qui garantissent que votre code fonctionnera probablement la plupart du temps, et que si vous rencontrez une erreur, il sera plus facile de déboguer. et beaucoup moins coûteux à modifier et à entretenir quelle que soit la personne qui travaillera sur ce code ultérieurement.

Le point saillant est qu'un code bien factorisé et bien testé permettra à AUTRES d'avoir confiance en votre code, qui est dans la plupart des cas plus important que votre propre confiance.

Si le code sale est bien testé, on peut y faire confiance. Le problème, c’est que les tests unitaires de codes corrompus sont généralement très difficiles et encombrants. C'est pourquoi le TDD est si bon. il révèle et élimine la saleté et les odeurs. En outre, les tests unitaires sont souvent la première chose à souffrir du temps perdu. Donc, si le gars le plus propre avait jamais créé le code le plus propre qu'il ait jamais écrit, je ne lui ferais toujours pas confiance, s'il omettait les tests unitaires en raison du temps imparti.

Les bons programmeurs (Quick & Dirty et autres) n’ont pas l’orgueil de supposer qu’ils ont raison. Ils supposent que tous les grands systèmes ont des bogues et des défauts, mais qu’à un moment donné, ils pourraient être suffisamment testés et révisés pour que le risque de défaillance ou le coût de défaillance soit suffisamment faible pour pouvoir être expédié.

Alors, pourquoi ces programmeurs, nommés Quick & Dirty, existent-ils? Mon hypothèse est la sélection darwinienne. Les programmeurs qui envoient rapidement du code pratique, expédient parfois avant les navires de compétition, l’épuisement du budget ou la faillite de la société. Par conséquent, leurs entreprises utilisent encore de nouveaux programmeurs pour se plaindre du gâchis à réparer. Ce qu'on appelle le code propre est également livré, mais pas assez différentiellement pour conduire les codeurs Quick & Dirty à l'extinction.

On pourrait probablement penser qu’une partie non optimale d’un code ne ferait aucune différence, en raison de sa courte durée de vie, de son faible impact sur les affaires ou du peu de temps dont il disposait pour le faire. La bonne réponse est que vous ne savez pas vraiment. Chaque fois que j'écoute quelqu'un dire que "c'est une petite fonctionnalité" ou "faisons en sorte que cela soit le plus rapide et le plus simple possible" et ne consacrons pas suffisamment de temps à réfléchir au bon design, les deux seules choses qui se produisent réellement sont:

1-) Le projet s'agrandit et la motivation de l'équipe diminue, travaillant sur un code rempli de "points de suture". Dans ce cas, le projet sera probablement une voie rapide vers le chaos.

2-) Le projet devient une solution non optimale et son utilisation commence à être découragée au profit d'une nouvelle solution ou d'un refactoring aussi coûteux qu'une nouvelle solution.

Essayez de toujours faire le meilleur code possible. Si vous n'avez pas assez de temps, expliquez pourquoi vous avez besoin de plus. Ne vous mettez pas en danger avec un travail mal fait. Soyez toujours un meilleur professionnel. Personne ne peut vous punir pour cela si vous êtes raisonnable. S'ils le font, ce n'est pas l'endroit où vous devriez travailler.

Discutez avec la personne âgée et évaluez l'impact des défaillances, le cas échéant. Par exemple, une situation dans laquelle vous pouvez réparer le nettoyage prend 1 jour et un code robuste nécessite des modifications de conception et d’architecture pouvant prendre de 4 à 6 mois plus un temps de validation supplémentaire pour valider complètement tous les flux de travaux impactés par la modification de conception.

Nous devons également prendre une décision en fonction du temps, de la capacité et des priorités de la liste. Une bonne discussion en équipe avec des seniors ou des personnes plus expérimentées peut aider à prendre une décision qui correspond le mieux à l'équipe et à ses résultats.

Le code propre est la première approche en tant que code sale permettant de sauvegarder les escalades, les décisions prises par les clients, les show stoppers, la réputation de l’organisation en jeu et bien d’autres encore, où le code sale permet de passer au code propre.