Refactoring du code legacy : recommencez à le modifier sans crainte, sans arrêter la roadmap

Presque personne ne nous appelle parce que le code est moche. On nous appelle quand le produit se vend, que l’équipe est compétente et que, malgré cela, chaque changement du système prend des semaines et traîne quelques régressions derrière lui.

• Chaque fonctionnalité prend plus de temps que la précédente
• De petites modifications provoquent des régressions inattendues loin dans le système
• Certaines parties du code, l’équipe préfère ne pas y toucher
• Les tests automatisés sont rares, et chaque release dépend de longues vérifications manuelles
• Une ou deux personnes seulement connaissent vraiment les modules critiques
• Une modification produit oblige à toucher de nombreux modules qui n’ont rien à voir avec elle
• Dans l’équipe, on commence à parler de tout réécrire de zéro

Toute la dette n’appelle pas la même réponse. C’est pourquoi nous travaillons selon deux approches différentes, et nous ne choisissons pas entre les deux a priori.

Au début du parcours, nous choisissons avec vous quelques indicateurs liés à ce qui coûte trop cher aujourd’hui, et nous les suivons dans la durée. Le choix dépend du système et de ce qui freine le métier ; par exemple :

• le lead time des modifications
• les régressions qui arrivent en production
• le temps nécessaire pour une release
• le temps pour mettre une nouvelle fonctionnalité en production

Nous ne promettons aucun chiffre avant d’avoir vu le code. Nous promettons de mesurer dès le début, pour que les progrès, ou leur absence, soient visibles de tous.

Le plan de sortie se décide dès le début

1. 01Nous fixons quelles compétences doivent rester dans l’équipe, et comment nous saurons qu’elles y sont restées
2. 02Nous réduisons la présence de QMates par paliers, pendant que l’équipe prend en charge les zones refactorisées
3. 03Nous laissons des tests, des frontières et des indicateurs que l’équipe sait lire et maintenir
4. 04Nous clôturons quand l’équipe fait vivre le refactoring dans son travail quotidien

• Nous ne réécrivons pas tout de zéro comme premier choix
• Nous n’arrêtons pas la roadmap pour ouvrir un chantier de refactoring
• Nous ne transformons pas le refactoring en migration cloud, comme une fin en soi
• Nous n’offrons pas de garanties génériques : nous préférons de petits pas, vérifiés par des tests et réversibles
• Nous ne faisons pas que de la formation : nous écrivons du code avec votre équipe
• Nous ne créons pas de dépendance à notre présence

Nous intervenons là où le changement coûte le plus cher, et nous nous arrêtons quand l’équipe sait avancer seule

Travaillez-vous aussi sur du code sans tests ?

Oui, et c’est même le cas le plus fréquent. On part des tests de caractérisation, qui décrivent le comportement actuel du système même là où il est incorrect, et deviennent le filet de sécurité pour modifier le code sans devoir en comprendre tout de suite chaque détail. Les tests grandissent avec le refactoring, en partant des zones les plus souvent touchées.

Écrivez-vous du code, ou faites-vous de la formation ?

Nous écrivons du code. Nous travaillons dans votre repository, en binôme avec vos développeurs, sur de vraies fonctionnalités et de vrais refactorings, et les techniques passent à l’équipe pendant le travail. Quand un moment de formation dédié est utile, nous l’ajoutons au travail sur le code, sans le remplacer.

Comment le refactoring cohabite-t-il avec le développement des fonctionnalités ?

Le refactoring se fait à l’intérieur de la livraison, en parallèle du travail sur les fonctionnalités. Avec le refactoring opportuniste, on améliore le code que la prochaine fonctionnalité doit toucher ; avec l’équipe dédiée, on débloque une zone pendant que le reste de l’équipe continue de livrer. Dans les deux cas, la roadmap ne s’arrête pas.

Travaillez-vous aussi sur les monolithes ?

Oui. Souvent, il suffit de rendre le monolithe modulaire, avec des frontières claires en son sein. Là où une partie doit vraiment être remplacée, nous utilisons le Strangler Fig : le nouveau code grandit à côté de l’ancien et prend en charge une fonction à la fois, pendant que le monolithe continue de fonctionner.

Combien de temps dure un parcours de refactoring du code legacy ?

Les premiers progrès mesurables arrivent après trois à six mois au moins. La durée totale dépend de l’ampleur et de la localisation de la dette, et le plan de sortie, avec ses conditions de clôture, se définit dès le début.

Par où commence-t-on ?

Par l’audit de la dette technique, qui produit une cartographie de la dette avec ses priorités et un plan d’action, et indique aussi quelle approche de refactoring est nécessaire. Si votre équipe préfère avancer seule avec ce plan, elle le peut.