"Pas besoin de faire du bon code, le projet est déjà très legacy…"

“Pas besoin de faire du bon code, le projet est déjà très legacy…”

#

Vous l’avez déjà entendue, n’est-ce pas ?

Bien que cela ne me fasse pas plaisir, cette réflexion est assez répandue dans l’IT.
Que ce soit de manière consciente ou inavouée, on a tous eu au moins une fois cette pensée dans notre carrière en voyant un projet en piteux état.

En soi, le raisonnement peut se comprendre :
Le code est ignoble. La solution est truffée de bugs. La logique est par endroits, voire en totalité tirée par les cheveux.

“Pourquoi s’embêter à essayer de faire quelque chose de bien dans ce contexte ? Tu n’y es pour rien à l’état actuel des choses.” dira la petite voix.

La réflexion peut se comprendre, mais c’est ici que s’arrête l’avocat du diable.

Le problème n’est vraiment pas à prendre à la légère. Il implique les devs, mais également le management, et par effet domino, l’ensemble de l’entreprise.

Mais pourquoi ?

#

En quelques mots, la théorie de la vitre brisée.

Le principe est le suivant : si une fenêtre cassée d’une maison n’est pas rapidement réparée, les autres suivront. L’endroit sera perçu comme délabré, menant à plus de casse, et le cercle vicieux s’installera.
La théorie s’applique parfaitement à nos projets IT.

Laisser passer l’ajout de code bancal, sous prétexte que le code existant est déjà médiocre, c’est valider sciemment que la qualité du projet ne fera que se dégrader, et que la situation va empirer.

La suite devient prévisible :
→ Le backlog va continuer de grossir, et les utilisateurs vont devenir de plus en plus mécontents (à juste titre.).

→ Le moindre correctif va prendre des allures de champ de bataille avec des devs faisant du stress post-traumatique rien qu’à l’énonciation du nom du projet (des souvenirs vous reviennent ?).

→ Le temps et les coûts de maintenance vont exploser, au point où certains en viennent à rêver de tout refaire from scratch (à supposer qu’il y ait du budget).

“Les développeurs n’ont qu’à se responsabiliser et le problème est réglé.”

#

Non. Je maintiens. Le problème implique l’ensemble de l’entreprise.

Si un développeur seul peut penser et agir ainsi, c’est déjà qu’à la base, la culture d’entreprise et d’équipe en place ne sont pas assez fortes pour guider le groupe.

Le code n’étant pas la propriété d’un développeur, ni même d’une équipe, mais de toute l’entreprise, c’est tout le collectif qui en paiera le prix le moment venu.

On fait quoi alors ?

#

Côté développeur, individuellement, on applique le principe bien connu “Boy Scout Rule” popularisé dans l’IT par Robert C. Martin dans son livre “Clean Code” : toujours laisser le code plus propre qu’on ne l’a trouvé à chaque intervention dans la codebase du projet.
Cela ne résoudra pas tout (par exemple l’introduction involontaire de bugs), mais ça limitera au moins les problèmes.

Côté équipe IT, on met en place des standards d’équipe ainsi que du monitoring et du suivi de métriques définies ensemble pour suivre la progression de la qualité du code et des services. Faites attention cependant à ne pas imposer des standards qui ne sont ni compris ni acceptés par le groupe. Cela ne ferait que créer des tensions et une difficulté à faire évoluer les pratiques dans le temps. Le groupe doit rester uni avant tout pour pouvoir avancer dans la même direction.

Côté management, on joue le rôle de médiateur et d’arbitre à la perfection : ni du côté du métier, ni des développeurs. Balancer plus d’un côté que de l’autre ne fera que causer des problèmes à terme.
À ce titre, la qualité doit être un facteur d’arbitrage dans l’équation au même titre que les deadlines et le budget. Si une concession sur ce point vient à être faite pour X ou Y raison(s), il faudra très sérieusement planifier les corrections pour y remédier dans le futur. Pas juste “il faudra” (on le connait tous, le fameux “on verra plus tard” (jamais…)). Planifier.
Restez attentif aux alertes remontées par les développeurs à ce sujet.

Ces principes couvrent l’essentiel concernant la problématique initiale exposée. Cette liste reste cependant non exhaustive. Bien d’autres pratiques peuvent être mises en place pour le bien de l’équipe IT et de l’entreprise, surtout dans le cadre d’une reprise en main d’un legacy. Vous en trouverez d’autres dans les chapitres et articles de ce site.