Au bout d'un certain temps de la vie d'un produit (environ 2 ans), les entreprises se retrouvent souvent à se poser cette question : "devons-nous tout écrire, tout recommencer ?"
Pourquoi en arrive-t-on à se poser cette question ? La grande majorité du temps, l'équipe n'arrive plus à maintenir son code, à développer de nouvelles fonctionnalités, elle a de plus en plus de mal à corriger les bugs, etc. Bref, elle s'est fait rattraper par la dette technique.
Mickael Wegerich - Duck conf 2021
Mais qu'est-ce que la dette technique ?
À l'origine, la dette technique est une dette contractée volontairement afin d'accélérer le développement à un instant T. Cette dette doit être remboursée immédiatement après (en réalité cette dette est au mieux partiellement remboursée, au pire pas remboursée du tout). Mais dans le langage courant, cette dette comprend aussi tout ce qui est généré au fil des développements de façon inconsciente par un manque de connaissances et/ou de compétences : c’est de cela que nous parle Mickael (liens de la vidéo et des slides).
On peut citer 4 causes principales :
À garder en tête : Nos choix nous rattrapent. Et les mauvais plus vite que les autres...
Point d’attention : le métier peut être complexe de par sa nature. Les solutions pour répondre au besoin que l’on cherche à résoudre peuvent être complexes. Essayons donc de ne pas ajouter de complexité superflue dans le code. Mais comment faire ?
"Le code est le reflet de notre organisation" Melvin E. Conway (cf autre talk de la Duck Conf sur ce sujet)
Les membres d’une équipe doivent discuter, partager, s’interroger, concevoir et décider ensemble. La communication est un pilier fort qu’il ne faut pas négliger dans une équipe.
La clean architecture (ou l’architecture hexagonale) aide à atteindre ce but en isolant, dans le code, la partie à valeur ajoutée c’est-à-dire le code métier.
En plus de structurer le code en séparant la responsabilité de chaque couche, ces patterns d’architecture vont aider à la construction d’une stratégie de test :
Il faut aussi savoir que, bien souvent, les tests sont trop couplés au code : en résumé, il y a une classe de test pour une classe de code. Ce qui implique que le moindre refactoring va casser les tests et rendre ce re-travail plus complexe et plus long à effectuer. Une meilleure façon de tester est de tester en unité fonctionnelle, c’est-à-dire que nous allons tester plusieurs classes par transitivité, rendant le code plus flexible.
Les développeurs ont besoin de savoir ce qu'ils sont en train de développer : ils doivent comprendre la problématique que le produit cherche à résoudre.
Sans rentrer dans le détail, voici deux outils qui aident les équipes à s’imprégner davantage du métier et de le faire transparaître dans le code : l’event storming (exploration d'une problématique métier) et le Domain-Driven Design.
Le partage, la veille, la lecture, les échanges, etc. permettent de ne pas rester sur ses acquis et de continuer d’apprendre, de se cultiver.
Le but derrière tout ça est d’éviter de se battre avec son code et de pouvoir prendre du plaisir ; de penser à demain, à la personne qui va devoir reprendre le code que “vous” avez livré. Cette personne qui sera d’ailleurs vous-même pendant un (bon) moment.
Améliorer la qualité du système va automatiquement motiver l'équipe. C’est un cercle vertueux : l’équipe produit un "beau" code (qualité des développements) → motivation des développeurs → soin du code → pas/peu de bugs en production → utilisateurs et clients contents → volonté de produire du “beau” code, etc.
Tout d’abord, prenez le temps : "Le code est un marathon, pas un sprint".
Nous avons tendance à courir après les US (pour tenir des engagements sûrement trop ambitieux). Résultat : développements rapides → génération de dette technique → dette non remboursée en totalité → la dette explose → l’équipe est sous l’eau… Stop !
⇒ Changer le postulat de base et ajouter une nouvelle entrée dans l'équation : formation, mindset, une personne/un expert, …
⇒ Accepter le changement, accepter de changer de façon de faire, accepter de ne pas savoir et continuer d’apprendre car souvent, comme le dit l’effet Dunning-Kruger (aussi appelé “effet de surconfiance"):
"on ne sait pas qu'on ne sait pas"
Si vous ne voulez pas refaire votre système tous les 2 ans, investissez dès le début et en continu.
En conclusion, être rattrapé par la complexité accidentelle n’est pas une fatalité, et heureusement, mais la combattre demande un effort permanent de la part de toute l’équipe. Et soyons réaliste : ne pas avoir de dette est illusoire… mais il faut savoir la résorber au fil de l’eau !