Reprendre un projet dont personne ne veut : ma première semaine

Reprendre le code de quelqu’un d’autre est un exercice qu’on n’apprend nulle part et qu’on pratique tout le temps. La tentation, la première semaine, est de tout lire pour « comprendre l’architecture ». C’est le meilleur moyen de perdre cinq jours et de ne rien retenir.

Voici comment je m’y prends. L’ordre compte plus que le contenu.

Jour 1 — Le faire tourner, sans aide

Objectif unique : lancer l’application sur ma machine, en suivant uniquement ce qui est écrit.

Je m’interdis de demander de l’aide pendant une demi-journée. Ce n’est pas de la fierté mal placée : chaque blocage que je rencontre est une information sur l’état réel du projet, et si je demande tout de suite, je perds cette information.

Ce que ce test révèle presque toujours : une variable d’environnement non documentée, une dépendance installée à la main il y a deux ans, un fichier de configuration absent du dépôt, une base de test qu’il faut peupler avec un jeu de données que personne n’a conservé.

Je note tout. Cette liste devient le premier livrable de la reprise, et souvent le plus apprécié — parce que personne n’avait mesuré la dette d’installation.

Jour 2 — Suivre un parcours de bout en bout

Je choisis le parcours principal — celui sans lequel l’application n’a pas de raison d’exister — et je le suis dans le code, de l’entrée utilisateur jusqu’à l’écriture en base.

Pas en lecture passive : je place des traces, je fais tourner, je regarde ce qui s’exécute réellement. Le code mort est fréquent dans une application ancienne, et rien ne ressemble plus à du code utile que du code qui ne s’exécute jamais.

En une journée, ce parcours donne 80 % de la compréhension utile : où sont les règles métier, comment sont organisées les couches, quelles sont les conventions implicites, où ça se complique.

Photo : Ylanite Koppens — licence CC0.

Jour 3 — Lire l’historique, pas le code

C’est l’étape que je recommande le plus et que les gens sautent le plus.

Je regarde les six derniers mois de modifications : quels fichiers changent le plus souvent, quels messages reviennent, où se concentrent les corrections urgentes.

Un fichier modifié quarante fois en six mois me dit deux choses. Soit c’est le cœur du produit — là où la valeur se crée. Soit c’est une zone instable où l’on n’arrive pas à corriger durablement. Dans les deux cas, c’est là qu’il faut regarder, et c’est une information qu’aucune lecture du code ne donne.

L’historique raconte aussi les urgences : les corrections livrées un vendredi soir marquent les endroits fragiles.

Photo : One Idea LLC — licence CC0.

Jour 4 — Corriger un bug minuscule, et le livrer

Le point le plus important de la semaine, et il n’a rien à voir avec la compréhension du code.

Je choisis le bug le plus insignifiant possible — un libellé, un tri, un message d’erreur — et je le mène jusqu’en production.

Ce que ce parcours teste : est-ce que je sais construire ? Déployer ? Vérifier que c’est bien en ligne ? Revenir en arrière si ça casse ? Combien de temps ça prend, et combien de personnes il faut solliciter ?

Tant que ce circuit n’est pas fait au moins une fois, on ne peut rien promettre à personne. Une équipe qui comprend parfaitement le code mais ne sait pas déployer ne peut pas tenir un délai de correction.

C’est aussi ce qui change la relation avec le client : livrer quelque chose, même minuscule, dans la première semaine vaut mieux que tous les rapports d’analyse.

Jour 5 — Écrire ce qui manquait

Je reprends mes notes du jour 1 et je rédige ce qui aurait dû exister : comment installer, comment lancer les tests, comment déployer, comment revenir en arrière.

Ce document a une propriété rare : il est écrit par quelqu’un qui vient de découvrir le projet, donc il ne suppose rien. C’est exactement ce qu’une documentation devrait être, et c’est impossible à produire une fois qu’on connaît le projet — on ne voit plus ce qui n’est pas évident.

C’est pour cette raison que je le fais le vendredi de la première semaine, et pas plus tard.

Photo : Ylanite Koppens — licence CC0.

Les trois pièges

Vouloir tout lire. Sur une application de plusieurs dizaines de milliers de lignes, la lecture exhaustive est impossible et inutile. On comprend un système en l’exécutant et en le modifiant, pas en le lisant.

Vouloir tout refaire. Le code hérité paraît toujours mauvais, parce qu’on ne connaît pas les contraintes qui l’ont produit. Cette bizarrerie apparente est souvent un contournement d’un problème réel. La règle que je m’impose : ne rien réécrire pendant le premier mois, sauf nécessité de sécurité.

Juger. C’est tentant et contre-productif, surtout devant le client. Le développeur précédent avait un budget, un délai et des informations que je n’ai pas. Ce qui m’intéresse n’est pas pourquoi c’est ainsi, mais ce que ça coûte de le changer.

Les questions que je pose à celui qui part

Quand le développeur précédent est encore joignable — ce qui n’est pas toujours le cas — je dispose souvent d’une heure, rarement plus. Autant ne pas la gaspiller en questions dont la réponse est dans le code.

Je pose cinq questions, toujours les mêmes.

« Qu’est-ce qui te réveillait la nuit ? » La réponse désigne directement la zone fragile. Personne ne connaît mieux les points faibles d’un système que celui qui l’a maintenu.

« Qu’est-ce qui a l’air bizarre mais qu’il ne faut surtout pas toucher ? » Il y a toujours un contournement dont la raison n’est écrite nulle part. Sans cette question, quelqu’un le « nettoiera » et le bug d’origine reviendra.

« Quelle partie referais-tu autrement ? » Elle donne la dette perçue de l’intérieur, souvent plus juste que n’importe quel outil d’analyse.

« Qu’est-ce qui n’est pas dans le dépôt ? » Certificats, tâches planifiées sur le serveur, scripts lancés à la main tous les mois, accès à un service tiers. C’est la question qui rapporte le plus, et elle n’est presque jamais posée.

« Qui appelles-tu quand ça casse ? » Il y a toujours un contact utile côté client ou hébergeur qui ne figure sur aucun document.

Je note les réponses le jour même. Cette page vaut plus que tout ce que je lirai dans le code cette semaine-là.

Ce que je livre au bout d’une semaine

Une procédure d’installation qui fonctionne, une correction déjà en production, une liste des zones fragiles repérées dans l’historique, et une estimation honnête de ce qu’il faudrait pour pouvoir s’engager sur des délais.

Ça paraît modeste. C’est infiniment plus utile qu’un audit de quarante pages remis trois semaines plus tard.