Réécrire ou réparer : comment décider pour un code existant

En général, réparer progressivement est plus sûr que tout réécrire. La réécriture complète séduit parce qu'elle promet un départ propre, mais elle est plus longue que prévu, et pendant ce temps votre produit ne progresse pas. Elle se justifie dans des cas précis, qu'on peut identifier.

L'analogie : la maison ou le terrain vide

Votre maison a des défauts : une fuite, une installation électrique ancienne, une cuisine mal pensée. Faut-il la raser et reconstruire ? Rarement. On vérifie d'abord les fondations. Si elles sont saines, on rénove pièce par pièce, et on continue d'y habiter. Si elles sont fissurées, rénover coûte alors plus cher que reconstruire.

Avec le code, c'est pareil : tout dépend de l'état des fondations.

Pourquoi la réécriture est plus risquée qu'elle n'en a l'air

• Le code existant contient des décisions invisibles. Des cas particuliers, des corrections de bugs, des règles métier apprises au fil du temps. Une réécriture les oublie, puis les redécouvre un par un, en production.
• C'est long, et le résultat est incertain. Pendant ce temps, il faut maintenir l'ancienne version en parallèle.
• Le nouveau code aura sa propre dette. Sans méthode plus rigoureuse, on retombe dans les mêmes problèmes.
• Vos utilisateurs ne voient rien. Pendant des semaines ou des mois, ils n'ont aucune nouveauté.

Quand réparer a plus de sens

Réparer (le terme technique est « refactoriser », c'est-à-dire réorganiser le code sans changer ce qu'il fait) est un bon choix quand :

• l'application fonctionne et rend service à ses utilisateurs ;
• le problème est localisé : une partie fragile, pas l'ensemble ;
• la structure générale est compréhensible ;
• vous voulez continuer à livrer des fonctionnalités pendant le chantier.

Quand réécrire se défend

• Les fondations sont inadaptées : la technologie choisie ne peut pas répondre à ce que le produit doit devenir.
• Plus personne ne peut modifier le code sans casser autre chose, et rien ne permet de le sécuriser.
• Le produit a changé de nature : ce qui était un prototype est devenu un service que l'on veut faire croître.
• La technologie est abandonnée et ne reçoit plus de mises à jour, notamment de sécurité.

Même alors, la réécriture peut se faire par morceaux : on remplace une partie à la fois, pendant que le reste continue de tourner.

Cinq questions pour trancher

1. L'application rend-elle service aujourd'hui, malgré ses défauts ?
2. Les problèmes sont-ils concentrés ou répartis partout ?
3. Les fondations (structure, données, technologies) tiennent-elles ce que vous voulez construire ?
4. Savez-vous ce que fait le code actuel, y compris dans les cas particuliers ?
5. Pouvez-vous vous permettre de ne rien livrer pendant la réécriture ?

Si vous répondez « oui » à la 1 et à la 4, réparer est en général préférable. Pour mesurer à quel point votre code vous freine, voir la dette technique.

L'option du milieu

On peut aussi stabiliser d'abord, décider ensuite : ajouter des tests sur les parties critiques, corriger les failles les plus urgentes, documenter. Cela redonne de la visibilité, et la décision de réécrire, ou non, se prend avec des faits plutôt que sur une impression. Si vous venez de récupérer le code, voir aussi reprendre un projet laissé par un freelance.

À retenir

Ne réécrivez pas parce que le code vous déplaît : réécrivez seulement si les fondations ne peuvent pas porter ce que vous voulez construire. Dans le doute, stabilisez d'abord, puis décidez avec des faits.

Et pour votre produit ?

Si vous hésitez entre réparer et repartir de zéro, notre accompagnement de reprise de projet commence par un état des lieux qui permet de décider sur des éléments concrets, sans parti pris pour l'une ou l'autre option. Nous pouvons en parler lors d'un échange de 30 minutes.