🌒 💯 🤵 Qu'est-ce que le «code propre» en 2020? ☕️ 🧒🏼 🖖

^{"Clean code" et un chat propre}

Ne nourrissez pas le pain des développeurs, discutons de la propreté du code: par exemple, le post de Dan Abramov "Goodbye, Clean Code" a récemment fait toute une histoire .

Mais en même temps, le concept même de «code propre» n'a pas de définition claire. Le livre principal sur cette question est «Clean Code» , où Robert «Oncle Bob» Martin déclare immédiatement: «combien de programmeurs, tant de définitions». Cependant, il n'en conclut pas «en parler est inutile», mais la conclusion «cela vaut la peine de comparer différentes définitions». Par conséquent, dans le livre, il a cité les vues de plusieurs programmeurs éminents sur ce qu'est le code propre.

Cela est devenu intéressant pour nous: en 2020, les idées de l'humanité sur le code propre sont restées les mêmes, ou ont-elles changé d'une manière ou d'une autre depuis la sortie du livre? Les opinions des différents informaticiens sont-elles différentes: peut-être que les backenders voient tout sous un angle et les testeurs sous un autre?

En avril, l'oncle Bob s'envolera pour Saint-Pétersbourg pour prendre la parole lors de trois de nos conférences, et elles ne prennent que trois directions différentes ( sur le développement .NET , sur les tests et sur JavaScript ). Par conséquent, nous avons demandé à plusieurs orateurs de ces conférences ce qu'est un code propre pour comparer les opinions des experts de l'industrie en 2020.

Et comme le sujet est creux, l'un d'entre vous ne sera certainement d'accord avec aucune des opinions. Dans ce cas, venez discuter dans les commentaires, c'est aussi amusant!

UPD: , . , . - . . 13 , .

DotNext

John est une légende de Stack Overflow, auteur de C # in Depth, et l'un des donateurs les plus célèbres de la planète. Il nous a donné cette définition:

«Pour moi, le code propre est un code ennuyeux, du point de vue de la mise en œuvre. La seule surprise en lui est combien il est dépourvu de surprises. Je dois sentir: "Oui, je pourrais écrire ceci", même si je ne le pouvais vraiment pas - à quel point il est bien conçu.

Lorsque l'abstraction est choisie correctement, l'implémentation est dérivée naturellement. Idéalement, cette abstraction devrait également sembler simple et évidente - bien qu'en fait, l'amener à un tel état puisse prendre des heures, des semaines, des mois de réflexion et d'expérimentation.

Le manque de surprises mentionné se poursuit plus tard: lorsque j'écris du code à l'aide d'une API bien conçue, mon code devient également évident et ennuyeux. "

Andrey Akinshin

Les visiteurs de DotNext n'ont pas besoin de présenter Andrey, mais pour le reste, nous vous dirons qu'il est connu pour son travail sur l'IDE Rider , la bibliothèque BenchmarkDotNet , ses rapports vifs et le livre "Pro .NET Benchmarking".

Lorsque nous lui avons demandé ce qu'il pensait du code propre, Andrei a fait référence à deux de ses anciens habraposts: «Code parfait et projets réels» et «Commenter ou ne pas commenter» . Et nous avons sélectionné pour vous quelques paragraphes à partir de là, avec lesquels quelqu'un voudra probablement discuter:

«J'adore le code parfait. Après tout, ce n'est pas seulement la bonne approche pour écrire des programmes, mais aussi un véritable art. En lisant une bonne liste, j'ai autant de plaisir que de lire un bon livre. Concevoir l'architecture d'un grand projet n'est pas plus facile que de concevoir l'architecture d'un grand bâtiment, et s'il fonctionne bien, le résultat n'en est pas moins beau. Parfois, cela me fascine de voir comment les modèles de conception sont entrelacés avec élégance pour créer un système logiciel parfait. J'admire le souci du détail quand absolument chaque méthode est si simple et directe qu'elle prétend être l'exemple classique du code parfait.

Mais, hélas, toute cette splendeur se décompose sur une dure réalité et de vrais projets. Si nous parlons d'un projet de production, les utilisateurs ne se soucient pas de la beauté de votre code et de la qualité de l'architecture, ils se soucient du bon fonctionnement du projet. Mais je pense toujours qu'en tout cas, vous devez vous efforcer d'écrire correctement, juste qu'il ne doit pas y avoir de fanatisme. »

Dylan Beatty

Habrachitateli peut se souvenir de Dylan sur son rapport réfléchi et vivant sur le travail avec le code hérité: pour Habr, nous avons fait son décodage . Et lorsque nous nous sommes tournés vers Dylan à propos du code propre, il a écrit un texte si détaillé et réfléchi qui le publie dans au moins un article séparé:

"Il est intéressant pour moi que le concept de" code propre "se soit propagé bien au-delà du cercle des personnes qui ont lu le livre de Robert Martin. J'ai parlé à de nombreux développeurs qui ont entendu les mots «code propre» mais n'ont pas lu le livre. Je les ai même rencontrés dans un codrev: "Tout est plutôt bien ici, mais pouvez-vous le nettoyer un peu?" - et une telle demande peut être fâcheusement inexacte s'il n'est pas évident de savoir ce que signifie «pur» dans ce contexte particulier.

En anglais, il y a des mots que l'on trouve souvent ensemble - «propre», «bien rangé», «organisé», «soigné» - et pour moi, en tant que locuteur natif de l'anglais, ils signifient tous des choses légèrement différentes. Je pense qu'il est utile de considérer certaines connotations de ces mots en relation avec le développement de logiciels.

Imaginez, par exemple, la cuisine d'un restaurant. Le mot propre dans ce contexte aura des connotations très spécifiques. Tout est lavé, stérilisé, il n'y a aucune menace d'infection due aux aliments crus, etc.

Mais cela ne signifie pas automatiquement que tout est bien organisé ici. Si vous avez déjà essayé de cuisiner avec un ami ou dans un appartement loué sur Airbnb, vous savez à quel point c'est agaçant quand les choses ne sont pas à leur place. Le détergent à vaisselle se trouve dans le buffet, dans lequel vous vous attendez à voir des pots, et le presse-ail n'est généralement pas clair où. Oui, tout est propre - il n'y a aucune menace que quelqu'un aime la nourriture cuite dans cette cuisine - mais travailler dans de telles conditions est ennuyeux.

Imaginez maintenant un atelier de menuiserie. À cet endroit, la saleté peut également causer des problèmes, mais ici, vous n'avez pas la même définition de la «propreté» que dans la cuisine. Vous pouvez nettoyer le ciseau jusqu'à ce qu'il commence à scintiller, mais il est peu probable que vous coupiez des saucisses avec. Le mot «propre» peut donc être très subjectif.

Mais pour moi, des mots comme «bien rangé» et «organisé» fonctionnent dans des contextes où «propre» ne fonctionne pas très bien. «Organisé» signifie que quelqu'un a soigneusement réfléchi à la façon d'organiser les éléments d'un lieu de travail particulier, et «rangé» signifie que ces éléments sont vraiment aux endroits qui leur sont attribués. Comme le dit le vieil adage, "tout a sa place et tout est à sa place".

Peut-être, dans le cas du code, nous devrions penser aux mots «propre» , «bien rangé» et «organisé» comme trois concepts différents. "Nettoyer"signifie que vous regardez les composants de la base de code - méthodes, fonctions, interfaces - et que vous ne voyez aucune raison de vous inquiéter. En nommant adhérer aux conventions; les noms des variables et des méthodes sont écrits sans erreur; dans les détails comme les retraits et les crochets adhèrent à un seul style; où que vous regardiez, vous voyez des preuves que, au niveau de base, cela est géré par des gens qui sont sérieux au sujet des affaires. C'est l'opposé d'un "code sale" - celui où beaucoup de fautes de frappe, d'accolades et d'indentation sont souhaitables dans les noms, les noms de fichiers inappropriés. Ce sont les choses qui sont corrigées comme par magie lorsque vous appelez l'outil de nettoyage de code dans quelque chose comme ReSharper.

"Organisé"- C'est une question d'architecture. Il s'agit de la façon dont vous pouvez plonger dans une base de code inconnue et trouver des choses où vous vous attendez à les voir. Les interfaces et les limites de domaine aident, pas interfèrent; les méthodes et les variables nommées sont non seulement correctement nommées du point de vue de la langue, mais reflètent également la langue unique de l'entreprise avec laquelle vous travaillez.

Et «bien rangé», c'est respecter les conventions locales ... une base de code dans laquelle vous pouvez trouver les bonnes choses à leur place, même si le modèle organisationnel spécifique n'est pas très clair pour vous à ce moment.

Je pense que lorsqu'ils parlent de la lutte pour un «code propre», cela signifie généralement ces trois choses. Mais définir l'objectif d'être complètement «code propre», en particulier lorsque vous travaillez avec un projet hérité complexe, peut être une perspective assez intimidante. Il serait peut-être utile pour nous tous de réfléchir un peu plus profondément et de déterminer quels composants du "code propre" bénéficieront vraiment au projet sur lequel nous travaillons actuellement. "

Heisenbug

Il s'agit d'une "conférence de test non seulement pour les testeurs": elle est à l'intersection du test et du développement. Par conséquent, beaucoup de ses orateurs comprennent les spécificités de ces deux mondes à la fois.

Ivan Krutov et Anna Chernysheva

Ivan et Anna travaillent dans des entreprises différentes, mais quelque chose les unit: les deux en savent beaucoup sur le sélénium. Nous avons parlé avec eux en même temps, nous avons donc obtenu une définition commune:

Ivan: «Pour moi, la définition la plus simple de code propre est un code compréhensible sans commentaire,« auto-documenté ». Un code jonché de commentaires qui tentent d'expliquer ce qu'il fait n'est pas du code pur. »

Anna: "Il me semble: c'est un code que vous pouvez rapidement comprendre, corriger un bug, le développer facilement, le compléter."

Ivan: «Vous pouvez également dire que c'est un« code pour lequel vous n'avez pas honte ». Généralement, ils disent que si vous regardez le code que vous avez écrit il y a six mois et que vous n'êtes pas terrifié, vous ne développez pas. Il s'avère que chaque année, votre code devrait devenir plus propre. »

Sebastian Dashner

Sebastian est le principal promoteur des développeurs Java d'IBM et peut souvent être vu lors de conférences Java. Mais comme il s'envole pour Heisenbug maintenant, nous lui avons posé des questions sur le code propre dans le contexte des tests, et il a répondu:

«D'après mon expérience, la qualité du code est importante non seulement dans le cas du code de production, mais aussi pour nos tests. Dans les tests, le code propre, les abstractions correctes et la délégation sont souvent négligés, ce qui conduit à un code de test que vous ne pouvez pas prendre en charge. Lorsque nous refactorisons le code de production et changeons son comportement, il devient clair si nous avons fait du bon travail sur la modélisation et la mise en œuvre de nos tests. »

Andrey Lushnikov

Andrey travaille sur un outil d'automatisation de navigateur Playwright, sur lequel nous avons récemment écrit . Sa définition s'est avérée être la plus concise:

«Un code propre est un code stupide et très compréhensible. Et le plus bête le mieux. "

Alexandra Svatikova

Alexandra est une experte en sécurité de l'information chez Odnoklassniki, qui "a commencé dans l'informatique en tant que développeur Java, mais a fait fausse route". Sa définition s'est avérée être la suivante:

«Le code pur a trois propriétés: un autre développeur peut facilement le lire et le comprendre, des améliorations mineures nécessitent un effort proportionné et l'effet d'un changement particulier peut être prévu.

En fait, cela signifie que le code est structuré, concis, suit les pratiques généralement acceptées pour le langage dans lequel il est écrit, ne contient pas de dépendances implicites ou d'effets secondaires et est couvert par des tests.

Holyjs

Andrey Melikhov

Andrei est connu de beaucoup pour le projet Devshakhta . Il n'est pas surprenant qu'une personne qui formule constamment ses pensées dans le podcast Devshacht ait clairement énoncé sa position:

«Robert« Oncle »Martin avec ses trois livres principaux (« Clean Code »,« The Clean Coder »et« Clean Architecture »), Il me semble qu'il essaie de répondre lui-même aux questions: qui, quoi et comment écrire. On peut discuter de l'exactitude de certaines de ses conclusions, mais voici ce qui est incontestable - ces livres sont basés sur une riche expérience personnelle et du bon sens. Et dans le cadre de cette idée, je peux dire que pour moi un code propre est un code qui serait écrit par une personne qui a trébuché sur un nombre considérable d'embûches dans sa vie et dans ce processus douloureux a appris à marcher avec une démarche prudente qui permet de les éviter.

Vous n'êtes peut-être pas à l'aise avec le style de cette personne, mais si vous le suivez, vous resterez certainement intact. Vous pouvez prendre ce style et le recycler, le rendre pratique pour vous. Ou vous pouvez désespérément plonger dans la rivière pour remplir vos propres cônes, développer votre propre style, tandis que les autres vous regarderont avec incrédulité, se déplaçant sous la supervision de camarades plus âgés.

Le code pur est un code facile à lire, à entretenir et à étendre. Ce sont ces trois aspects qui jettent des bases solides pour des applications qui doivent vivre pendant des années face à des exigences externes volatiles. À savoir, ces applications que nous écrivons dans les grandes entreprises "

Alexandra Kalinina

Alexandra est membre du comité du programme HolyJS, elle possède une vaste expérience en programmation - et bien qu'elle ne soit pas avec Heisenbug, elle connaît également les tests de première main (unité, intégration, E2E, B2B). Voici son texte:

«Le code propre est désormais un concept simple, mais il est assez difficile à comprendre. Il me semble qu'un code propre peut être obtenu en observant les règles suivantes:

- chaque morceau de code individuel devrait pouvoir évoluer ou croître / s'améliorer indépendamment des autres morceaux, mais en même temps conserver l'idée / l'intégration originale avec d'autres morceaux (SOLID aide beaucoup, et aussi la règle «toutes les décisions qui peuvent être prises plus tard doivent être prises plus tard»).
- Le code doit être lu comme un livre fascinant, avec des noms et des désignations typiques compréhensibles. Par exemple, si vous décidez d'écrire une histoire, elle aura très probablement une structure typique comme une introduction, une intrigue, un point culminant et un dénouement. Même si vous êtes le seul à travailler sur un projet, le code doit être facilement lisible par vous à tout moment, quelle que soit l'architecture, le langage ou les frameworks choisis.
- Le code doit avoir une structure claire. Ceux. la raison pour laquelle tel ou tel morceau de code est dans le projet doit être comprise.
"Chaque ligne de code doit être justifiée d'un point de vue commercial"

Nicolò Ribaudo

Nicolo, alors qu'il était encore étudiant, est devenu l'un des principaux développeurs du compilateur Babel (nous l'avons déjà interrogé séparément). Sa version s'est avérée être la suivante:

«Un code propre est un code qui peut être facilement divisé en petits composants atomiques.

«Atom of code» est le plus petit ensemble d'instructions possible qui a une signification indépendante et ne dépend pas inutilement du contexte environnant: les noms des variables et des opérations sont suffisamment descriptifs pour que le lecteur n'ait pas besoin d'allouer de mémoire supplémentaire dans sa tête pour stocker leurs valeurs et les modifications possibles, ainsi que non il fallait chercher ailleurs dans le code pour comprendre ce que signifie le résultat de cet «atome». Plus les atomes sont petits, plus il est facile de comprendre ce que fait le code.

Le code peut être propre quel que soit le langage de programmation ou le paradigme: les atomes peuvent être implémentés comme de petits objets, des fonctions ou même comme de petits morceaux de code qui ne sont pas isolés syntaxiquement. "

Conclusion

Enfin, lorsque les opinions ont été recueillies, nous les avons montrées à l' oncle Bob lui - même et lui avons demandé s'il voulait dire quelque chose. La réponse s'est avérée être:

«Je soutiens pleinement les commentateurs ci-dessus. J'ajouterais une seule chose que Michael Feathers a dit un jour: "Un code propre a toujours l'air d'avoir été écrit par une personne qui se soucie."

Sa conclusion semble très amicale. Mais le code propre est un sujet tellement discutable que pendant que l'un de vous hoche la tête, quelqu'un d'autre est probablement en feu, ressentant quelque chose comme ceci:

« : „ , ”. , , : . , !»
« „ ”? „” , — , , „” — !»
«Les mots« vous pouvez remplir vos bosses pendant que les autres regardent avec perplexité »semblent désobligeants, comme si seuls les imbéciles le faisaient. Mais tout ce qui se fait de mieux et d'innovant apparaît lorsque vous remplissez vos cônes et comprenez leurs raisons, et pas seulement en suivant de vieux livres! »

UPD 12 mars: Bien que l'oncle Bob ne puisse pas venir chez nous, nos conférences de Saint-Pétersbourg ( pour les développeurs .NET , les testeurs et les développeurs JavaScript ) sont peu susceptibles de contester le code propre. Sur les sites de conférence - toujours des versions à jour des programmes. Restez à l'écoute et abonnez-vous à nos newsletters - une fois par semaine, nous parlerons des changements.

Qu'est-ce que le «code propre» en 2020?