Reprendre ce qu’un autre a construit
Tout système hérité paraît pire qu’il n’est, pour la même raison que toute ville inconnue paraît mal conçue.
Tôt ou tard, vous héritez de quelque chose : une base de code, une automatisation, un tableur dont trois services dépendent. Celui qui l’a construit est parti ou occupé, ça fonctionne, et personne ne sait dire pourquoi.
L’envie de réécrire a presque toujours tort
Le travail d’un autre semble mauvais parce qu’on en voit toutes les cicatrices et aucune des raisons. Cette condition bizarre au milieu d’une fonction n’est pas de la négligence : c’est le correctif d’un problème client de 2023 que personne n’a noté.
Réécrire jette ces raisons non documentées et les redécouvre un incident à la fois. Donnez-vous une règle : pas de réécriture avant trois petites modifications réussies. À ce moment-là, soit vous comprenez assez pour réécrire correctement, soit vous aurez découvert que tout va bien.
Trouvez ce qui est porteur
Dans tout système hérité, une petite partie fait l’essentiel du travail réel et une grande partie est décorative : vieilles expériences, chemins morts, fonctions inutilisées. De l’intérieur, elles se ressemblent.
Deux moyens peu coûteux de les distinguer. Regardez ce qui change le plus souvent : le code souvent modifié est l’endroit où vit réellement l’activité. Et regardez ce qui s’exécute le plus. Tout ce qui n’a été ni modifié ni exécuté depuis un an est candidat à la suppression, et supprimer est le moyen le plus rapide de rendre le reste compréhensible.
Trouvez la personne qui se souvient, avant d’en avoir besoin
Il reste presque toujours quelqu’un qui était à proximité au moment de la construction — pas forcément l’auteur. Une personne du support qui se rappelle l’incident, un collègue qui a relu, le client qui a demandé l’exigence étrange.
Parlez-lui la première semaine, tant que vos questions sont naïves et bon marché, plutôt qu’au troisième mois quand vous êtes bloqué. Trente minutes alors épargnent des jours plus tard, et sa mémoire s’effrite chaque mois d’attente.
Faites une petite modification et livrez-la
Lire du code inconnu apprend étonnamment peu ; le modifier apprend tout. Choisissez quelque chose de trivialement petit et menez-le jusqu’en production.
Vous apprendrez ce qu’il fallait vraiment savoir : comment cela se construit, ce qui casse quand on y touche, si les tests signifient quelque chose, qui s’en aperçoit. C’est la vraie carte, et elle ne figure dans aucun document. Notez ce que vous avez appris lors de cette première modification : vous êtes la seule personne qui verra ce système avec un regard neuf, et ce regard disparaît en un mois.
Questions fréquentes
Faut-il réécrire un système hérité ?
Pas d’abord. Le travail d’un autre paraît mauvais parce qu’on voit ses cicatrices sans les raisons ; cette condition bizarre est souvent un correctif non documenté. Faites trois petites modifications réussies avant d’y penser.
Comment savoir quelles parties comptent ?
Regardez ce qui change le plus et ce qui s’exécute le plus. Le code souvent modifié est là où vit l’activité ; ce qui n’a été ni modifié ni exécuté depuis un an est candidat à la suppression.
Que faire la première semaine ?
Trouver qui était présent lors de la construction — pas forcément l’auteur — tant que les questions sont naïves, et mener une modification triviale jusqu’en production. Puis noter ce que vous avez appris.
