Tenir une base de code qu'on n'a pas écrite

La première réaction devant un code hérité est toujours la même : on voudrait tout réécrire. Le nommage est incohérent, les tests manquent, les dépendances ont trois ans de retard. Et le pire, c'est que la réécriture semble raisonnable — on connaît le métier, on a la stack moderne, ça ira plus vite.

Ça n'ira pas plus vite. Un système en production contient des années de décisions dont la plupart ne sont écrites nulle part. Réécrire, c'est les redécouvrir une par une, en production, avec des clients.

Semaine 1 : lire, ne rien changer

La règle est stricte : aucune modification pendant la première semaine, même une faute de frappe. Uniquement lire, exécuter, noter.

Ce que je cherche, dans l'ordre :

1. Comment ça démarre. Si je n'arrive pas à lancer le système sur ma machine en une journée, c'est le premier problème à résoudre, avant tout le reste.
2. Par où passe l'argent. Facturation, paiement, calcul de prix : ce sont les zones où une erreur coûte immédiatement. Je les localise et je les laisse tranquilles.
3. Ce qui tourne la nuit. Tâches planifiées, imports, exports. Ce sont les parties que personne ne regarde et qui cassent en silence.
4. Ce qui a été modifié récemment. L'historique du dépôt dit où sont les problèmes actuels mieux que n'importe quel audit.

À la fin de la semaine, j'ai une carte. Pas un rapport de qualité — une carte : les zones sûres, les zones à risque, les zones inconnues.

Semaine 2 : poser un filet

Toujours pas de changement fonctionnel. On installe ce qui permettra d'en faire sans peur.

Des tests de caractérisation sur les zones à risque : on ne teste pas ce que le code devrait faire, on fige ce qu'il fait aujourd'hui. Si un calcul de frais donne 4 950 pour 5 000, le test dit 4 950. C'est peut-être un bug ; ce n'est pas le moment de le corriger, c'est le moment de le savoir.

Un journal d'erreurs centralisé, s'il n'existe pas. On ne peut pas tenir un système dont on ne voit pas les pannes.

Un environnement de préproduction avec des données réalistes. La moitié des bugs hérités ne se reproduisent qu'avec de vraies données — celles saisies à la main en 2016 avec une virgule au lieu d'un point.

Semaine 3 : la première modification

Petite, utile, visible. Un bug connu, agaçant, sans risque. L'objectif n'est pas la correction ; c'est de traverser toute la chaîne — modification, revue, test, déploiement — une première fois, et de découvrir ce qui manque à chaque étape.

C'est là qu'on apprend que le déploiement se fait à la main depuis le poste d'une personne, ou que les migrations ne sont pas versionnées. Ces découvertes valent plus que trois semaines de réécriture.

Ce qu'on dit à l'équipe

Le code hérité a été écrit par des gens qui avaient moins de temps, moins d'information et des contraintes qu'on ne connaît pas. Le mépris du code précédent est le meilleur moyen de perdre ceux qui l'ont écrit — et ce sont souvent ceux qui savent pourquoi il est comme ça.

Je pose une règle simple : on peut dire « je ne comprends pas pourquoi c'est fait ainsi ». On ne dit pas « c'est n'importe quoi ». La première phrase ouvre une conversation. La seconde la ferme.

Quand réécrire, alors

Quand la carte est complète, que le filet est en place, et qu'une zone précise coûte plus à maintenir qu'à remplacer. Par module, jamais en bloc. Avec les tests de caractérisation comme contrat : le nouveau module doit donner 4 950 tant que quelqu'un n'a pas décidé, par écrit, que c'est 5 000 qu'il faut.

Le système qu'on hérite n'est pas un problème à effacer. C'est la seule documentation fiable de ce que l'entreprise a réellement besoin de faire.