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

166

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?

Karl Bielefeldt
la source
40
Ma théorie est que tous les codeurs se situent quelque part entre les "mémorisateurs" et les "compréhenseurs", et que peu d'entre eux savent bien faire les deux. Plus vous vous en souvenez, plus vous pouvez vous permettre de créer votre code. Que le code soit propre ou non, faites-le fonctionner, testez-le!
Job
35
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". heh ... l'enfer sera gelé avant qu'il ne soit " plus tard " ...
Carlos Campderrós
28
Tous les programmeurs ne pensent pas de la même façon - on m'a donné du code pour maintenir cela qui n'avait aucun sens pour moi pendant des mois, jusqu'à ce qu'un jour, ce soit comme si un interrupteur de lumière était inversé, alors que je réalisais quelle était la structure d'organisation globale et tout cela. compris pourquoi ils l’avaient fait comme ils l’ont fait. L'aurais-je fait de cette façon? Non, mais ça a fonctionné.
Joe
12
@ joe - +1 - Certains programmeurs sont trop rapides pour rejeter un code qui ne correspond pas à leur idée personnelle de "bon code". Vous devez toujours essayer de comprendre la pensée qui sous-tend un corps de code et son style, souvent vous apprendrez quelque chose d’utile.
James Anderson
10
How do quick & dirty programmers know they got it right?Parce que ça marche :)
Rachel

Réponses:

100

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.

mince
la source
24
+1 pour "l'impact de l'échec est faible". Mon calcul mathématique préféré du risque est le risque = conséquence réelle de l'échec x probabilité d'échec x conséquence perçue de l'échec (selon mon expérience, le risque perçu sur lequel les parties prenantes restent souvent bloquées)
Trav
7
"Le code a une durée de vie courte. Par exemple, vous transformez un tas de données en un format standard avec un programme ad-hoc." Que se passe-t-il si la transformation n'est pas correctement effectuée, mais que les divergences dans les données ne sont remarquées que bien plus tard?
Joey Adams
3
@Trav Donc, juste pour confirmer, si la conséquence réelle de l'échec est massive, mais que ma conséquence perçue de l'échec est nulle, il n'y a aucun risque que ce soit?
Christian Stewart
3
@ChristianStewart D'un point de vue purement mathématique, votre assertion serait correcte. Cependant, dans la pratique, une perception de conséquence égale à zéro n’annulerait pas le poids de la probabilité x conséquence réelle. La perception est placée dans la formule pour prendre en compte les craintes organisationnelles qui influencent souvent les décisions d'atténuation. L'absence d'une telle peur ne diminue en rien la probabilité ou les conséquences réelles. Ainsi, on devrait supposer que la perception est toujours au moins égale à 1 (puisqu'elle peut amplifier mais ne pas nier en aucune façon le risque réel)
Trav
1
@Trav Sinon, renommez-en un. En d'autres termes, le risque devrait être remplacé par le risque perçu , car si nous estimons que l'échec n'entraîne aucune conséquence, nous croyons également qu'il n'y a aucun risque.
Delioth
237

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).

Hossein Aarabi
la source
31
Chaque fois que j'entends le "nettoyer plus tard" ou "nous le ferons quand les choses ralentiront un peu" je suis toujours tenté de commencer à chanter "Demain, demain, je t'aimerai demain. C'est toujours un jour awaayyyyy." Cela pourrait être juste moi, cependant.
JohnFx
8
Beaucoup d’entre nous ont été dans cette position plutôt malheureuse. C'est assez déroutant d'être légué à la dette technique des autres .
Mark Booth
34
Le problème actuel est de classer les autres programmeurs dans les titres cowboy, quick & dirty ou autres. Chaque programmeur a certains modes d'échec, et lire le code de quelqu'un d'autre est très difficile, et il est très difficile de trouver vos propres échecs. Tout cela ensemble signifie que les gens qualifient trop facilement les autres programmeurs de mauvais, tout en pensant que leur propre code est parfait
tp1
3
@ tp1: Les bons programmeurs peuvent écrire du code facile à lire. Ils le font en demandant à quelqu'un d'autre de le lire et en clarifiant tout ce qui n'est pas clair. Avec la pratique, la partie qui n'est pas claire en première lecture va diminuer.
kevin cline
9
@ JimThio, pensez-vous sérieusement que l'un des programmeurs mentionnés ci-dessus a déjà écrit intentionnellement du mauvais code? Avez-vous déjà lu du code écrit par vous-même il y a quelques années? Avez-vous trouvé ça bon? Les chances sont, vous avez fait de votre mieux à l'époque, et vous voyez toujours beaucoup de choses à améliorer dans ce code maintenant.
Péter Török
103

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.

Dan Ray
la source
9
Ou peut-être que si on l'utilise durement pendant des décennies, cela finira probablement par ressembler à un gâchis. S'il n'est pas utilisé (du tout ou pendant longtemps), il n'aura aucune chance d'accumuler des dégâts.
Inutile
7
"Tous ceux qui travaillent dans ce secteur depuis longtemps seraient probablement d’accord pour dire qu’il serait possible de jouer avec un logiciel plus ou moins indéfiniment." Ce serait possible, mais pourquoi le faire? Une fois que vous avez défini votre norme de qualité, vous la concevez, la mettez en oeuvre, la testez, corrigez les bogues, testez-la à nouveau, puis ne la touchez plus. Cela prend plus de temps que de le pirater, mais une fois que vous avez atteint votre objectif (la fonctionnalité requise est implémentée et testée), il est bien évident que vous ne devez plus jouer avec le code. Juste mes 2 cents.
Giorgio
7
+1 - dans le monde réel, il y aura toujours un compromis entre la qualité du code et le respect des délais. Je préférerais avoir un programmeur capable de produire rapidement un code raisonnable plutôt qu'un perfectionniste qui passe des mois à se demander s'il doit appeler une méthode "sérialiser" ou "écrireToFichier".
James Anderson
3
tu l'as dit. J'ai travaillé dans une organisation où, dans la pièce voisine, se trouvait une équipe qui travaillait depuis 5 ans sur les exigences fonctionnelles d'un nouveau système. Aucune ligne de code n'a jamais été écrite pour celui-ci. Beaucoup de codeurs sont les mêmes (surtout les juniors, fraîchement sortis du collège avec des idées bien arrêtées sur le fait que le code doit être beau et respecter des "standards" spécifiques, sinon c'est mauvais) et va, à moins d'arrêter, bricoler sans fin avec quelque chose qui était parfaitement fonctionnel il y a des mois (I parfois encore cette tendance, je pense que nous avons tous). Mais au bout du compte, l’important est de le faire sortir de la porte.
Jwenting
6
@Giorgio: Je ne suis pas d'accord avec votre "superstition" selon laquelle un travail de qualité prend plus de temps que de le pirater. Cela pourrait être vrai si vous assimilez la programmation à la frappe. Si l’on considère le cycle de vie du logiciel dans son ensemble, les choses vont beaucoup mieux et donc plus rapidement si on tient à la qualité.
ThomasX
85

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.)

Péter Török
la source
8
"croyant avec bienveillance (et par ignorance) qu'ils font de leur mieux compte tenu des circonstances." Résumé parfait du problème. Le n ° 1 s'est précipité à cause de contraintes et a fait de son mieux. Le n ° 2 arrive et a hérité du chaos, de nouvelles échéances et fait de son mieux. Jusqu'au 20e pauvre âme qui ne pourrait faire de son mieux s'il avait des années pour réparer les dégâts. C'est pourquoi je pratique la règle du scoutisme, "laissez-le plus propre que vous ne l'avez trouvé". Donnez à cette sève une chance de combat - ce pourrait être vous.
Steve Jackson
1
C'est drôle, je sens l'inverse depuis que j'ai commencé à tester mon code (au travail). C'est comme devenir paresseux; il n'y a aucune raison de vraiment comprendre votre code, car un autre code vous
signalera des
8
Vous écrivez des tests unitaires en partie pour prouver que votre propre code fonctionne. Plus important encore, vous écrivez des tests unitaires afin que d' autres développeurs puissent modifier votre code en toute confiance.
Stephen Gross
4
Donald Knuth: "Méfiez-vous des bogues dans le code ci-dessus; je n'ai fait que le prouver, mais je ne l'ai pas essayé." haacked.com/archive/2007/11/29/...
MarkJ
1
@ Izkata - si vous ne comprenez pas ce que vous faites, les tests unitaires sont probablement rompus et il est donc vrai que le code comporte les mêmes erreurs que les tests. En outre, même avec une couverture de décision à 100% et des tests unitaires précis, il est possible (bien qu'inhabituel) d'avoir un bogue que les tests ne révèlent pas.
Steve314
33

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)

Tom Squires
la source
6
Bonne citation, mais ce n'était pas Gandalf. C’était Pippin qui expliquait pourquoi lui, Frodo et Sam ne devaient pas traverser tout le pays jusqu’au Buckleberry Ferry, juste avant le départ de Hobbiton.
Daniel Roseman
22
Correction: "Les tests unitaires. C'est le seul moyen d'avoir un faux sentiment de sécurité dans le code (sale ou pas)". Les tests unitaires sont bons, mais ils ne garantissent rien.
Coder
8
Quand je veux découvrir des bugs cachés, je montre l'application à mon patron. Je l'appelle le test du boss, il doit être fait après les tests unitaires. Il a une aura de magnétisme qui attire toutes sortes d’insectes bizarres ainsi que des rayons cosmiques directement dans les registres de la CPU.
Monsieur Smith
8
Pendant que nous citons, vous pourriez aussi aimer "Les tests montrent la présence et non l'absence de bugs" - Edsger Dijkstra
Timothy Jones
2
-1 tests ne donneront pas les résultats escomptés: les tests unitaires ne prouvent rien, ils vous donnent une mesure de confiance, mais ne valent rien de plus. Ils sont une bonne mesure, mais ne supposez pas qu’ils signifient plus qu’une petite sous-section de code fonctionne exactement comme vous l’écrivez, elle ne dit pas que vous l’écrivez correctement ou qu’elle interagira correctement avec quoi que ce soit d’autre. Bien que ce soit généralement une bonne mesure, mais qu’ils ne servent à rien avec un code de merde, ils aggraveront la situation en vous donnant plus de code à modifier avec chaque refactor.
Bill K
15

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.

jfrankcarr
la source
1
+1 pour souligner que les décisions concernant les mesures de qualité doivent être justifiées par les besoins de l'entreprise.
Stephen Gross
+1 pour * "La compétence à développer consiste à comprendre quel niveau de" perfection "doit être utilisé pour un projet particulier." ... Établissez une norme minimale quant au degré de "retouche" que votre entreprise jugera acceptable risque en termes de qualité, alors respectez-le.
S.Robins
11

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.

Kevin Peterson
la source
1
En d'autres termes, les modules peuvent être Q & D, mais l'architecture doit être correctement nettoyée.
Kromster
9

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.

siamii
la source
1
+1 Pour une raison quelconque, j'aime lire ces histoires. Ils ne me rendent même plus triste ou en colère.
Sam Hocevar
-1 pour écrire n'importe quel type de classe _______Manager.
Brian Driscoll
@SamHocevar Run, ne marchez pas, à thedailywtf.com
Mawg
7

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."

BillThor
la source
1
Tout à fait un développeur éthique que vous avez là!
Stephen Gross
6

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.

Fredrik
la source
6

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.

Suboptimus
la source
5

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.

Bernard
la source
5

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! entrez la description de l'image ici

Poisson Or Pourpre
la source
4

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.

Raku
la source
5
Parfois, vous ne disposerez pas d’argent si vous n’envoyez pas maintenant ... mais le fait d’expédier maintenant vous permet de payer dix fois plus pour le nettoyer, puis d’autres parce que vous avez battu vos concurrents sur le marché et la reconnaissance de la marque d'abord.
CaffGeek
2
Je ne suis pas d'accord. Si l'argent est déjà limité, vous dépensez votre revenu pour le prochain produit et vous le ferez jusqu'à ce que votre entreprise meure ou s'agrandisse. Dans ce dernier cas et très probablement, les développeurs d'origine ne seront plus là pour réparer l'ancien code.
Raku
Battre les autres sur le marché ne garantit pas que le public acceptera votre produit. Si un produit contient trop de défauts, il est préférable d’espérer que vous aurez l’argent supplémentaire nécessaire pour appliquer un bon marketing fumée et miroir et que vous aurez une relation brillante et indulgente avec votre clientèle. Ce n'est pas une position ou. La solution consiste à équilibrer le risque et la récompense, et à proposer le produit de la plus haute qualité que vous puissiez fournir rapidement. Vos compétences seront jugées en fonction de la qualité du produit que vous publiez, et les dommages qu'un logiciel défectueux peut causer à votre image peuvent être irréparables.
S.Robins
1
Commencez à différer à votre guise, mais l’histoire regorge d’exemples où il était plus important d’être là au bon moment, disponible pour celui qui le voulait, que d’être le meilleur produit possible. Il y a toujours un coût d'opportunité, toujours toujours.
Warren P
1
Warren, c'est essentiellement ce que je disais. À mes yeux, le coût d'opportunité pour ramener le code à maintenable augmente de façon exponentielle, plus vous le retardez. Si votre entreprise est dans une position où elle peut survivre au désastre d'inviolabilité, parce que les ventes se sont bien déroulées et que le code n'était pas trop sale, bon, mais que se passerait-il?
Raku
4

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."

Trav
la source
3

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).

Caleb
la source
3

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.

S.Robins
la source
2

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.

Morten
la source
2

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.

hotpaw2
la source
C'est vrai. J'ai vu au moins un produit pouvant être expédié en raison du code Quick & Dirty, des verrues, etc. Il s'est avéré que quelques jours au lieu d'un mois signifiait un saut de deux mois sur la concurrence. Le produit a été couronné de succès et le code Quick & Dirty a finalement été remplacé par un meilleur code. Depuis lors, depuis que j’ai constaté que j’essayais de mieux visualiser la qualité de mon code du point de vue de l’ingénierie, mais aussi du point de vue commercial / concurrentiel. Remarque: l'interface de ce code était correcte, c'était l'implémentation qui était fragmentaire.
J Trana
0

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.

Thiago Gama
la source
0

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.

Mendy
la source
4
cela ne semble rien offrir de substantiel sur les points
gnat