Au revoir, Clean Code (2020)

Adieu au rangement du code

• Un collègue a intégré tard le soir du code qu’il avait écrit toute la semaine.
• Implémentation d’une fonctionnalité de redimensionnement de formes sur le canvas d’un éditeur graphique.
• Le code fonctionnait, mais il était répétitif.

Le lendemain matin...

• Le responsable a demandé un entretien en privé et a demandé d’annuler les modifications du code.
• Au début, ce fut un choc, mais il a fini par comprendre que la décision du responsable était la bonne.

Une étape

• S’obséder du « code propre » et se consacrer à l’élimination des doublons est une étape que traversent de nombreux développeurs.
• Quand on manque de confiance en son code, il est tentant de lier son estime de soi et sa fierté professionnelle à ce qui est mesurable.
• Une fois qu’on a appris l’abstraction, on a envie d’en utiliser dès qu’on voit du code répétitif.

L’avis de GN⁺

• L’important est que la recherche de la « propreté » du code n’est pas une fin en soi, mais une sorte de mécanisme de défense face au traitement de systèmes complexes.
• Le « code propre » aide les développeurs à se repérer en territoire inconnu, mais il faut aussi savoir ne pas s’y accrocher exclusivement et pouvoir le laisser de côté.
• Cet article offre aux développeurs un point de vue intéressant sur l’importance de la collaboration et du pragmatisme dans le processus d’écriture et de maintenance du code.

[GN⁺]

Avis sur Hacker News

• « Clean Code » a besoin d’un repositionnement de marque

  • L’objectif de Clean Code est de rendre le code plus simple et plus facile à maintenir
  • La valeur d’un logiciel réside dans sa capacité à évoluer au fil du temps
  • Si le refactoring a rendu la maintenance plus difficile, alors ce n’est pas du Clean Code
  • Ne pas avoir discuté du refactoring avec le développeur d’origine est un problème distinct du Clean Code

• La duplication de code peut parfois être une bonne chose, mais ce n’est pas une preuve que le Clean Code est mauvais

  • Remplacer 10 lignes de calculs mathématiques répétés par une fonction peut rendre le code plus propre
  • Il faut relire les PR et les refuser si elles ne respectent pas les critères
  • Ignorer l’importance du Clean Code finit par produire une base de code sur laquelle plus personne ne veut travailler
  • La leçon à retenir est qu’il faut une meilleure communication et plus de retenue

• Un collègue écrivait beaucoup de code par copier-coller

  • Le refactoring doit être soumis à la review
  • Qu’un manager intervienne directement pour ordonner un revert est un mauvais signal
  • La leçon n’est pas que le copier-coller vaut mieux que d’écrire des fonctions

• Il est probable que la version « propre » ait remplacé un code encore plus sale

  • Il faut en tirer des leçons sur la manière de travailler en équipe

• Une review par les collègues est nécessaire lors des modifications de code

  • Il faut reconnaître l’absence de bons processus
  • Le refactoring du code ne doit être fait que lorsqu’il est nécessaire

• Dans la finance, on traite souvent de produits similaires mais différents

  • Il est important d’éviter la surabstraction tout en conservant un code propre

• Des langages comme Haskell maximisent l’abstraction au niveau du langage

  • Ils minimisent les abstractions propres au projet, mais avec un coût d’apprentissage élevé

• Déplacer des calculs mathématiques répétitifs dans une fonction séparée relève du Clean Code

  • En revanche, refactorer des fonctions de redimensionnement qui ressemblent à la construction d’une interface est une erreur

• Explication des mauvaises abstractions

  • Le problème vient d’une conception faite sans suffisamment réfléchir aux usages futurs

• Rob Pike a dit : « un peu de copie vaut mieux qu’un peu de dépendance »

  • Le principe DRY ajoute parfois de l’abstraction, mais si cette abstraction n’est pas suffisamment orthogonale, elle aggrave au contraire le problème