Draft Tidy First, by Kent Beck

drafts/2024-02-04-tidy-first/index.md

@@ -0,0 +1,124 @@
+---
+title: Tidy first ?
+writer: Kent Beck
+tags: [dette technique, Pareto]
+---
+
+> Don't make software design such a big deal that you're in danger of not doing it
+> -- page 23, chapitre II
+
+La complexité d'un programme informatique dépend de la manière dont il est organisé et découpé, comment ces différentes parties sont couplées entre elles, et combien elles sont en cohésion les unes avec les autres.
+La **cohésion** correspond au degré d'adéquation entre les différents éléments d'un même module.
+En terme de programmation, ceci correspond au fait que ces éléments évoluent ensemble et forment un tout cohérent.
+Le **couplage** correspond à la nécessité pour un module de disposer d'informations appartenant à un autre module [^1].
+Ce couplage sera représenté par la nécessité de modifier un élément alors que nous avions prévu d'en modifier un autre.
+Il s'agit en gros de la manière dont notre cerveau sera à même de traiter la complexité d'une architecture - et il est donc dans l'intérêt de tout le monde de faire en sorte que le nôtre puisse être abordé de la manière la plus simple possible.
+
+[^1] Un très bon article sur [Baeldung](https://www.baeldung.com/cs/cohesion-vs-coupling) explique très bien cette distinction, avec plusieurs exemples concrets.
+
+Le développement logiciel est un processus humain : il ne s'agit pas juste de créer un ensemble d'instructions à destination d'un ordinateur, mais plutôt que les intentions prévues à destination d'un ordinateur, puissent être comprises par d'autres personnes.
+
+## Valeurs, options et changements
+
+Les logiciels apportent de la valeur de deux manières :
+
+1. Ce qu'il fait aujourd'hui,
+2. Ce qu'il sera en mesure de faire demain.
+
+Les options (et particulièrement les greffons et possibilités d'extensions) constituent la magie économique d'un développement.
+Ce qui interfère avec les options sont les changements de structure ou d'organisation : un employé qui quitte l'entreprise, une distance (de compréhension) avec les utilisateurs ou le coût d'un changement à appliquer.
+En cas de situations chaotiques, créer des options sera votre meilleur allié : cela vous permettra de proposer une base concrète, et d'attendre que la situation se calme avant de pouvoir la faire évoluer.
+
+## Nettoyage de code
+
+"Nettoyer" du code au même moment que d'y ajouter des fonctionnalités entraine un risque de collision, surtout dans le cas d'interactions entre plusieurs personnes ou équipes.
+
+Le problème aussi est qu'au plus nous nettoyons du code, au plus nous aurons envie d'en retirer des morceaux, et au plus le risque de collisions augmente.
+En même temps, au plus du code est propre, au moins les revues (de code) nécessitent du temps.
+Pour résumer ceci :
+
+> Au plus nous passons du temps à nettoyer du code, au moins il sera nécessaire d'y passer du temps.
+
+Dans les équipes disposant déjà d'une bonne culture, le nettoyage d'un morceau de code ne nécessite aucune revue.
+Mais avant d'arriver à ceci, il sera nécessaire d'avoir réaliser des mois d'expérimentation, de pratiques et de revues.
+
+> Il faut noter que la loi de Pareto s'applique également dans le cas du nettoyage de code : 80% des modifications seront appliquées dans 20% des fichiers.
+
+Plusieurs pistes de refactoring sont proposées :
+
+* Guard clauses,
+* Dead code,
+* Ordre de cohésion,
+* Auto-explication des variables,
+* Ordres d'extractions,
+* One big pile,
+* Nécessité d'expliquer des commentaires,
+* Suppression de commentaires récurrents.
+
+### Guard clauses
+
+Le fait de n'avoir qu'un seul `return` dans une fonction est un héritage du langage Fortran.
+Nous pouvons cependant interrompre volontairement (après une inversion de condition, par exemple) le déroulement d'un programme pour en améliorer sa lisibilité.
+Ceci permet de court-circuité le cerveau, qui en est ainsi aidé dans sa compréhension.
+
+Si on voit ceci :
+
+```
+if (condition)
+    if (not other condition)
+        ...some code...
+```
+
+Il est possible d'en améliorer facilement la lisibilité en plaçant une guard clause et en inversant les conditions.
+Il sera ainsi plus facile (et plus compréhensible pour le cerveau) de lire ceci, car il n'aura aucune combinaison à réaliser - dès que la première condition aura pu être éjectée, il pourra se concentrer sur la suivante sans avoir à se soucier d'interférences :
+
+```
+if (not condition)
+    return
+
+if (other condition)
+    return
+
+...some code...
+```
+
+### Dead code
+
+Si du code n'est jamais utilisé, jamais exécuté et ne sert plus à rien pour le moment, supprimez-le.
+S'il est nécessaire de le retrouver, cela pourra être fait au travers du contrôle de versions ou de le redévelopper.
+Mais dans l'immédiat, supprimez-le.
+
+### Ordre de cohésion
+
+Faites en sorte que les éléments qui dépendent les uns des autres soient proches (physiquement) les uns des autres.
+Ceci en facilite la lecture et l'accessibilité, et permet de se créer facilement une carte mentale de l'emplacement de certains éléments.
+Le langage `C#` permet de créer des espaces de noms indépendants de l'emplacement physique où se trouve le fichier, tandis qu'en Python, ces espaces de noms sont explicitement liés à l'emplacement sur disque : si nous connaissons le namespace dans lequel évolue un élément, il sera facile de l'y retrouver sans aucune obfuscation.
+
+A termes, tout ceci peut également facilier le réarrangement de ces éléments.
+
+### Auto-explication des variables,
+
+
+
+### One big pile
+
+L'objectif du nettoyage de code est d'apporter une forme de paix et de satisfaction.
+_A contrario_, y passer du temps à chaque revue de code ne va faire qu'ajouter de la frustration et de l'énervement, car ces revues doivent tenir compte d'autres éléments (couplage, découplage, cohésion, ...).
+Il faut faire attention à ne pas sombrer en abîme.
+
+### Commentaires d'explication
+
+Il faut faire attention si des commentaires sont présents pour expliquer le fonctionnement d'une méthode ou d'un morceau de code, car cela pourra créer du couplage entre le code et ses commentaires - et il n'existe pour le moment
+
+### Suppression de commentaires récurrents
+
+
+## Coûts d'un développement informatique
+
+L'équivalence de Constantine indique le coût du développement d'une application est pratiquement égal au coût de sa maintenance.
+Après la *release* initiale, un gros travail doit être réalisé afin de stabiliser l'existant.
+Ensuite seulement, cette maintenance se stabilisera.
+
+Une autre manière de visualiser ceci consiste à regarder le cumul des coûts :
+
+![](development-cost.drawio.png)