Le refactoring est une activité quotidienne pour les développeurs, mais elle est souvent perçue comme complexe. D'après les statistiques sur mon projet précédent, un mauvais refactoring se classe au 6e rang parmi les causes les plus fréquentes d’introduction de bugs. Cependant, ne pas refactorer n'est pas une solution, car c'est un processus essentiel pour maintenir la qualité et l’évolutivité d’un projet logiciel. Au fil du temps, la dette technique s'accumule, ce qui ralentit le développement, démotive les intervenants du projet, impacte la stabilité des livrables et freine la mise à l’échelle d'un projet. Le refactoring est un outil indispensable non seulement pour prévenir l’augmentation de la dette, mais également pour la réduire dans les cas les plus extrêmes.

J'ai récemment assisté à des conférences lors de l’événement Mobilis in Mobile et suivi une formation sur ce thème. J'aimerais partager les points clés sur le refactoring et comment le maîtriser. Dans ce dernier article de la série sur le refactoring, je vais partager quelques techniques pour convaincre votre équipe que cette démarche n’est pas un luxe, mais une nécessité. Car, soyons honnêtes, il n’est pas toujours facile de leur faire comprendre pourquoi il est important d’y investir du temps et des ressources. En général, si un décideur n'est pas convaincu, deux choses se produisent : soit le développeur laisse passer et remet à plus tard, soit il fait du refactoring en douce, sans l’accord explicite du client.

Mais travailler en cachette ou repousser constamment le refactoring est rarement une bonne stratégie. Alors, comment convaincre que ce travail est non seulement utile, mais crucial pour le succès du projet ? Voici quelques pistes pour y parvenir.

Règle #1: Cernez le besoin de votre interlocuteur

Si vous parlez à un CTO, vous pourrez insister sur la qualité du produit, mais si vous avez affaire à un chef de projet ou un responsable marketing, il vous faudra plutôt insister sur les utilisateurs ou le retour sur investissement. Votre discours doit être adapté à votre interlocuteur et pour cela il faudra comprendre les intérêts de la personne à qui vous vous adressez. Le Client Value Model peut vous aider à structurer votre approche en mettant le focus sur ce qui compte le plus pour le décideur. Dans une boîte produit, le client peut-être le comité exécutif ou le CEO. Dans une société de services, cela sera souvent un client externe.

Le Client Value Model

Ce framework consiste à identifier les priorités du décideur (temps de mise sur le marché, coût total, satisfaction des utilisateurs, etc.) et ce qui l’énerve (être mis de côté lors des interviews utilisateur, ne pas être accompagné dans la décision des futures fonctionnalités, etc.). Ensuite, le principe est d’ajuster votre discours en conséquence. Cela signifie que vous devez présenter le refactoring comme une réponse directe aux objectifs de votre interlocuteur. Par exemple, si son principal souci est la rapidité de livraison des nouvelles fonctionnalités, expliquez que le refactoring permettra d’accélérer les futurs développements.

Quand un concessionnaire veut vous vendre une voiture, il analyse vos critères de recherche. Si vous cherchez une voiture fiable parce que vous en avez assez d’aller chez le garagiste pour changer des pièces, il vous dirigera vers une Toyota en vantant l’incroyable gestion des défauts pratiquée dans leurs usines, faisant ainsi de cette marque l’une des plus fiables. Pour un autre client qui recherche une voiture au design avancé, il lui parlera du centre de design de Toyota situé dans le sud de la France.

Règle #2: Oubliez le jargon, parlez en résultats

Simplifiez: Ne les perdez pas dans les détails

Quand il s'agit de convaincre un décideur, éviter le jargon technique est primordial. Parler de "complexité cyclomatique" ou de "design patterns" ne fait souvent que brouiller le message. Ce que le client comprend, ce sont les gains, les conséquences, les risques et le coût. Parlez-lui en euros ou en temps passé : il le comprend bien.

Si vous demandez à votre garagiste pourquoi il faut changer un filtre ou vérifier les freins, il ne vous parlera pas de la pression hydraulique dans les cylindres. Il vous dira simplement : "Si vous ne le faites pas, votre voiture risque de tomber en panne en pleine route, et vous devrez payer bien plus cher." Adoptez la même approche.

Exprimer le Gain

Expliquez en quoi le refactoring est bénéfique pour le projet : amélioration de la stabilité, réduction des bugs, augmentation de la satisfaction utilisateur. Ce sont ces gains concrets qui parlent au décideur. Par exemple, vous pourriez lui expliquer que faire ce travail maintenant évitera de devoir revenir dans quelques mois pour corriger un problème bien plus coûteux, tout comme remplacer un filtre dans une voiture prévient de futures pannes.

Aborder Les Coûts

À l'inverse, il est également important de mettre en évidence le coût de l’action et le risque de l'inaction. Quelles sont les conséquences si le refactoring n'est pas réalisé ? Plus de bugs, des correctifs plus longs, voire des crashs en production.

Imaginez que votre garagiste vous explique qu’ignorer une réparation maintenant augmentera de 10 % le risque de panne, avec un coût de réparation bien plus élevé plus tard. Le refactoring fonctionne de la même manière : en retardant ces améliorations, les coûts futurs augmentent de manière exponentielle.

Règle #3: Laissez les chiffres parler d'eux-mêmes

Tout comme vous estimez le coût de développement des nouvelles fonctionnalités, vous pouvez estimer celui du refactoring. Comparez simplement le temps nécessaire pour ajouter une nouvelle fonctionnalité avec et sans refactoring.

Si l’argument du temps de développement est souvent assez simple pour un développeur, ce n’est pas le seul indicateur pour le coût. Par ailleurs, il vous faut aussi des arguments pour le gain. Voyons ensemble quelques indicateurs clés de performance (KPIs) qui seront vos alliés.

Suivez ce qui compte : les indicateurs clés du succès du refactoring

La baisse d’un indicateur avec le temps peut témoigner d’une nécessité de refactorer tandis qu’un suivi de l’augmentation peut témoigner du succès d’un refactoring. Pensez à réduire le scope de vos indicateurs sur la zone du projet concernée. Voici quelques indicateurs qui suivent cette règle :

• La couverture de test
• Le taux de réussite des builds de CI
• La vélocité des développeurs
• La fréquence de livraison
• La note de satisfaction donnée par les utilisateurs
• La note de satisfaction donnée par les développeurs
• Le nombre de nouvelles fonctionnalités

Et à l’inverse, ceux où une augmentation est un mauvais signe :

• Le nombre de bugs
• Le nombre d’utilisateurs impactés par des bugs majeurs
• Le temps de correction des bugs
• Le nombre de crashs en production
• Le nombre d’alertes du linter

Ces KPIs vous serviront à montrer les coûts croissants de l’inaction et les gains de vos refactorings. Vous pouvez aussi trouver d’autres arguments comme le risque de régression, le fait qu’il n’y ait pas d'autres développements prêts, le turnover dans l’équipe, etc.

Utilisez des supports visuels. Parfois, un simple diagramme montrant l’augmentation des bugs sur une fonctionnalité clé sera plus convaincant qu’un long discours.

Dans l’idéal, pour respecter la règle  #2 sur le langage commun, vous savez convertir ces indicateurs en euros représentant la perte d’argent pour le client. Pour cela vous trouverez de nombreux exemples réels dans le livre The Economics of Software Quality.

Règle #4: Traitez les petits refactoring maintenant pour éviter les gros soucis plus tard

Imaginez un garagiste. Lorsque vous lui confiez votre voiture pour une révision, il ne vous demande pas si vous voulez qu'il vérifie s'il y a des fuites d'huile. C'est évident pour lui : il le fait, c'est une question de sécurité et de performance. En tant que développeur, vous devriez adopter cette approche : si un refactoring est rapide et améliore immédiatement la qualité du code, faites-le sans avoir à démarrer une longue négociation. Cela revient à respecter la règle du Boy Scout : laissez toujours le code plus propre que vous ne l'avez trouvé.

En résumé : faites du refactoring une priorité non négociable

Convaincre un client d’investir du temps dans le refactoring demande de la préparation, des arguments clairs et une compréhension des priorités de votre interlocuteur. Ne vous perdez pas dans les détails techniques inutiles. Expliquez le gain du refactoring, mettez en opposition le coût du refactoring et le coût de l’inaction, et proposez des indicateurs pour suivre le succès du refactoring. Donnez vos arguments à l’oral avec un support visuel. Enfin, n’oubliez pas : tout comme un garagiste ne vous demande pas si vous voulez qu’il vérifie les éléments de base de votre voiture, certains refactorings doivent être faits sans même en discuter.

Plus vous arriverez à faire accepter l’investissement dans des refactorings significatifs, plus ce sera facile de convaincre pour les suivants, sans compter tous les indicateurs que vous aurez déjà en place.

‍