Bonjour, Habr!
Il n'y a pas de fin à parler de
code propre , mais le prochain article de Dave Nicoletta est très métaphorique et, espérons-le, vraiment digne d'être traduit. Que ce soit un peu «édifiant», comme l'avertit d'avance les lecteurs dans l'article original.
Bonne lecture.
À la maison, au fil des ans, une mauvaise habitude s'est installée. En utilisant n'importe quel outil, nous avons toujours oublié de le remettre à sa place. La prochaine fois que quelqu'un en avait besoin, il devait passer plus de temps à chercher un outil qu'à résoudre un problème. Le plus triste, c'est que même celui qui a pris l'instrument en dernier et l'a jeté n'importe où était voué exactement aux mêmes recherches. Il s'est souvent avéré qu'il était plus rapide d'acheter de nouveaux équipements que de chercher l'outil que nous avons - nous en sommes sûrs! - quelque part qui traîne.
Nous avons donc eu quatre tournevis cruciformes Philips de taille moyenne, trois avec une fente plate, un tas de pinces et de clés supplémentaires, des jeux d'adaptateurs. Sans parler de l'impressionnante collection de stylos, écheveaux de ruban adhésif, piles et autres bonnes choses éparpillées partout.
Une fois que nous avons décidé: ça suffit! Alloué leur place pour toutes choses et mettre les choses en ordre avec notre inventaire. Outils remis à une œuvre de bienfaisance. Nous nous sommes efforcés de cultiver l'autodiscipline et nous ne mettons toujours les outils à leur place qu'après avoir travaillé avec eux. La qualité et le volume de travail par unité de temps ont fortement augmenté. Le stress, l'argent gaspillé et l'humeur gâtée sont devenus beaucoup moins.
Mettre de l'ordre dans le garage de l'entreprise
Et si les mécaniciens automobiles travaillant dans un garage d'entreprise laissaient tomber des outils n'importe où? Ils passeraient plus de temps à chercher des outils qu'à travailler. Les détails seraient mis au mauvais endroit, perdus, rouillés, gâtés, ils seraient simplement volés. Les coûts d'approvisionnement augmenteraient considérablement.
Il faudrait plus de temps pour terminer les tâches, mais la qualité du travail diminuerait. Lorsqu'un mécanicien doit travailler avec des outils rouillés, usés et cassés, il lui est difficile d'ajuster et de fixer correctement les pièces. De plus, l'habitude d'organiser un désordre dans l'atelier affectera inévitablement la qualité du travail.
Les clients en auront assez des transferts interminables de fin d'emploi. Bientôt, ils iront à des ateliers plus fiables. D'une manière ou d'une autre, je m'en passerai Peut-être que les analogies avec le développement et le support logiciel sont déjà évidentes.
Mettre de l'ordre dans le développement logiciel
Regardons un exemple spécifique: le refactoring incrémentiel.
Cette expression est déroutante pour beaucoup. Je ne sais pas quel mot les confond: «incrémental» ou «refactoring».
Le refactoring incrémentiel (progressif) est fondamentalement différent de celui à grande échelle. Il semble à beaucoup que tout refactoring soit nécessairement «à grande échelle», qu'il doit être «autorisé» par quelqu'un, et donc, soi-disant, le travail doit être traîné. En fait, c'est si l'on néglige le refactoring en cours de travail, alors tout est significativement retardé.
La plupart des entraîneurs techniques, y compris moi-même, expliquent à peine la différence dans ce cas; non pas parce que cette différence est par définition compliquée, mais parce qu'elle est vraiment difficile à formuler en mots. Cependant, je pense que l'habitude d'examiner attentivement l'inventaire disponible et de surveiller l'offre est une bonne analogie dans ce cas.
Refactoring progressif
Faire un refactoring progressif, c'est comme maintenir l'ordre sur un établi, même en hauteur de travail. Utilisez un tournevis - mettez-le en place. Nous ne reconstruirons pas, avant chaque nouvelle tâche, un atelier pour cela. Le point, c'est plutôt la capacité de terminer ... comment terminer ce que vous avez commencé. Dépouiller les extrémités.
Le refactoring progressif ne prend pas beaucoup de temps supplémentaire et ne nécessite pas la permission de quelqu'un d'en haut. Pour cette question, vous devez demander la permission de ne pas nettoyer dans le code, si vous devez vous précipiter. La capacité de garder constamment le code propre doit en fait être considérée comme la compétence professionnelle de base d'un programmeur. Il est dommage qu'aujourd'hui, le «code propre» ait besoin de propagande, et certains programmeurs s'opposent même à apporter une telle pureté. Le refactoring progressif n'a absolument rien avec le refactoring architectural à grande échelle, ce qui nécessite vraiment une planification minutieuse, une allocation de temps, d'argent et de personnes.
Règle du scout
Dans la programmation, il existe une soi-disant «règle scout»: garder le code au moins aussi propre qu'il a été reçu. Il en va de même pour le stockage des outils de travail à domicile. Si nous recherchons des pinces, mais notez que le tournevis à fente est accidentellement arrivé à la croix et que le tournevis cruciforme est arrivé à la fente, nous, dans le processus, les avons mis à leur place. Nous n'avons pas besoin d'une approbation officielle pour ce faire.
C'est ainsi que fonctionne le refactoring progressif. Devant nous se trouve un morceau de code, et nous devons ajouter une nouvelle condition à la liste des constructions disponibles. Nous remarquons que la liste est implémentée comme un grand bloc if / else. Nous décidons qu'il doit être repensé comme un commutateur ou un opérateur de sélection, tout en ajoutant une condition. On peut dire: est-ce vraiment bien mieux que le bloc if / else? Oui, vous avez raison: pas grand-chose. Mais un peu mieux. Lorsque quelqu'un lira ensuite ce code après vous, il pourra le raffiner encore mieux, puisque vous avez amélioré sa position de départ. Si vous avez déjà fait quelque chose comme ça auparavant, alors vous avez probablement remarqué qu'en lisant attentivement toutes les conditions, vous avez parfois trouvé des constructions en double, puis l'ordre non optimal des expressions; peut-être avez-vous rencontré une condition qui ne peut jamais être remplie, ou même un «trou» logique à travers lequel la séquence de contrôle entière passera par le bloc if / else, et certains cas ne seront pas traités du tout. Réjouissez-vous simplement de l'avoir découvert maintenant, et pas tard dans la nuit, lorsque vous recevez un ticket correspondant du service d'assistance technique. À un tel moment où les yeux se collent, il n'y a absolument aucun désir de comprendre le code confus.
Peut-être que nous ajouterons de nouvelles fonctionnalités à l'application et remarquerons que la fonction / méthode que nous avons écrite est très similaire à une autre (une autre) que nous avons déjà dans la base de code. N'ayant passé que quelques secondes, nous nous débarrasserons de ces duplications, même sans les outils supplémentaires qui sont proposés à nos services dans des IDE chics. Vous pouvez refactoriser sans hésitation, puisque nous nous sommes habitués à l'autodiscipline et garantissons que des microtests (tests unitaires) couvrant ce cas ont déjà été écrits. Le refactoring manuel n'est pas terrible. En fin de compte, trouvez au moins une raison pour laquelle non?
Le «long terme» n'est généralement pas aussi long qu'il n'y paraît
Souvent, j'entends différentes personnes dire que la refactorisation apporte des avantages «à long terme». Bien que, en théorie, ce soit, ici, dans le monde réel, vous devez constamment remettre le travail en termes stricts. Cependant, si nous parlons de maintenir la pureté du code au moyen d'un petit refactoring progressif, le «long terme» dure exactement jusqu'au moment où quelqu'un d'autre touche la base du code. Exactement jusqu'à la prochaine fois.
La mauvaise nouvelle est que le contraire est vrai. Si vous ne nettoyez pas le code pendant que vous travaillez, il se détériore rapidement. Nous n'avons pas d '«airbag» de dix ans qui nous permettrait d'accumuler le mariage en toute impunité jusqu'au début des problèmes. Le prochain changement qui devra être effectué prendra un temps inacceptable de notre part, le risque de régression du code augmentera, et la situation sans une attention appropriée ne fera qu'empirer.
Si nous piratons juste pour satisfaire le désir du client (et il veut le produit fini le plus rapidement possible), comment allons-nous continuer à répondre à ces demandes après nous être assurés qu'aucune modification rapide n'est apportée, puisque nous avons apporté le code à l'État confusion, et il est impossible de le maintenir?
Qu'est-ce qui est rapide, qu'est-ce qui est lent?
Les clients voudront toujours que vous travailliez plus fort, quelle que soit la vitesse à laquelle vous les organisez. Le moyen le plus efficace de réduire le délai de sortie est de tout faire correctement; bien faire; nettoyer constamment les extrémités, toujours, sans exception. Couper les coins pour «accélérer», dans la pratique, nous ne faisons que ralentir, et pas dans la «perspective à long terme» éphémère, mais ici et maintenant.
Lorsque le client exige que vous travailliez plus rapidement, cela ne signifie pas qu'il vous permet de travailler avec insouciance. Naturellement, il lui semble évident qu'il ne doit pas, après chaque demande, nous rappeler qu'il s'intéresse à la qualité. La haute qualité est impliquée comme l'un des composants de notre travail.
En tant qu'ingénieurs, nous choisissons nous-mêmes de considérer la refactorisation progressive comme l'élément de base de notre activité professionnelle. Nous ne demandons pas si nous pouvons travailler comme il se doit, tout comme le chirurgien ne demande pas au comptable s'il a le temps de se laver les mains avant l'opération. Le temps passé sur l'opération est exactement autant de temps que nécessaire pour que l'opération soit réussie. Le patient doit être soigneusement retiré de l'appendice, et après la sortie, la personne pourrait reprendre une vie normale - sans infection de la plaie et sans tampon dans l'abdomen. Cela ne fera qu'empirer si une personne est retirée de la salle d'opération dix minutes plus tôt que nécessaire, puis les complications commencent.
Souvent, dans ce cas, ils parade que si "tout est fait selon la science", alors il s'avère "trop long". Non, en fait, «trop long» est le temps qu'il faut pour corriger les conséquences si le travail était fait à la hâte et sans le professionnalisme approprié. Le rétablissement d'une infection est un véritable choc pour le patient et sa famille, cela affectera inévitablement son travail. Une deuxième opération, dans laquelle un tampon oublié doit être découpé de l'abdomen, est une intervention beaucoup plus grave, et elle ne sera nécessaire que parce que la personne a été opérée à la hâte pour la première fois.
Lors de la programmation, si vous devez effectuer cinq régressions du code en raison du fait que quelqu'un l'a écrit à la hâte, vous ne pouvez pas parler de «gagner du temps». Au contraire, les modifications sont apportées plus longtemps. Le travail n'est pas «fait» tant qu'il n'est pas fait correctement. Si l'équipe devait passer des heures et des jours à corriger les erreurs après la «préparation du projet», alors c'est du temps perdu qui pourrait être consacré à d'autres travaux utiles. C'est un manque à gagner.
De telles erreurs ont des conséquences semblables à des vagues et entraînent des pertes de temps et d'argent à long terme, et parfois la perte de clients. Un stress supplémentaire tombe sur les épaules des ingénieurs eux-mêmes; moral bas, roulement élevé du personnel. Par conséquent, un vissage toujours plus dur et une nouvelle diminution de la moralité et de la participation au travail.
La dette technique comme métaphore
Chaque fois que vous abordez le sujet de la refactorisation progressive, quelqu'un vous rappellera certainement la dette technique. Ils diront: "Nous avons un tel délai qu'il est juste nécessaire de réduire les coins." Ils ajouteront que dans ce cas, l'équipe accumule consciemment la dette technique, guidée par les besoins de l'entreprise.
Ceux qui le disent ne comprennent pas cette métaphore, et peut-être pas du tout de métaphores.
La métaphore n'est pas destinée à être une description complète et complète de la chose caractérisée.
Une métaphore aide en général à donner un aperçu d'un aspect de cette chose.
Les gens ont tendance à remplacer une chose par sa métaphore, puis à opérer avec une métaphore comme si elle et
la chose décrite est une seule et même chose. Non, ce n'est pas la même chose. Le point.
De plus, il est courant que les gens interprètent une métaphore au-delà de son contexte d'origine. Ainsi, le sens de la métaphore est flou et devient de moins en moins utile.
Ward Cunningham a proposé une métaphore de la dette technique, décrivant les interactions avec les clients dans le secteur financier. Il a cherché une métaphore adaptée à ce contexte particulier, pour souligner comment la réalisation progressive des opportunités permet de créer une boucle de rétroaction au cours de laquelle le programme est constamment optimisé. Il ne voulait pas dire "couper les coins afin de créer l'illusion d'un développement rapide".
Le concept original de la métaphore de la dette technique impliquait que le code était nécessairement maintenu propre. Les personnes qui comprennent le problème laissé dans le code évoluent pas à pas vers sa solution, et le code sera toujours suffisamment précis pour que de telles améliorations progressives puissent y être apportées. Il ne s'agit pas du fait que certaines raisons techniques peuvent justifier pourquoi le code est indésirable et nécessite des corrections constantes.
Couper les coins pour une remise rapide du travail n'est pas une accumulation de dette technique. Il s'agit d'un hack courant.
Qui est responsable?
Pour obtenir une livraison rapide, vous devez vous débarrasser des problèmes lorsque vous travaillez. L'un de ces problèmes est le code indésirable. Vous pouvez vous débarrasser de cet obstacle étape par étape en apprenant à travailler en autodiscipline. Dans ce cas, peu importe comment vous travaillez - selon le modèle "cascade" ou selon "l'aggail". Nous choisissons nous-mêmes comment travailler chaque fois que nous touchons le clavier.
Je résume. Si vous travaillez correctement, y compris le nettoyage des extrémités, cela ne profitera qu'au client, aux sponsors, aux gestionnaires, à ceux qui soutiendront notre code à l'avenir et, bien sûr, pour nous-mêmes.