Si ça marche, on n'y touche pas !

Sur les projets informatiques, la maintenance et la modernisation de l'existant sont rarement prioritaires par rapport à l'ajout de fonctionnalités. Au fil du temps, le code devient moins pertinent, moins performant, plus difficile à analyser et à maintenir.
La dette technique s'accumule progressivement et freine les nouveaux développements, allonge les délais de débogage, instille l'incertitude.

Arrive le moment où l'équipe grogne et parvient à décrocher un budget pour la réduction de la dette technique. Mais comment la mesurer ? Par quel bout commencer ? Comment optimiser le budget alloué ?

Voici une méthode simple et efficace qui devrait vous permettre de prendre conscience de l'état global du projet, et de faciliter l'identification et la priorisation des portions les plus atteintes par la dette technique.

Le ménage par le vide

Imaginez que vous perdiez tout le code source d'un module de votre application. Pas de backup, pas de gestionnaire de sources, plus rien. Quel serait l'effort nécessaire à sa restauration ? Toutes les informations sont-elles disponibles pour le redévelopper à l'identique ? D'ailleurs, est-il seulement souhaitable de le redévelopper à l'identique ?

L'exercice consiste à réunir l'équipe, et à estimer chaque module de l'application (technique ou métier) selon les axes suivants, notés de 1 à 3 :

• Facilité de redéveloppement
• Volonté de réutiliser l'ancien code s'il était retrouvé

Facilité de redéveloppement

1. L'équipe maîtrise parfaitement le code existant et est capable de le redévelopper. La documentation est à jour et détaille toutes les règles fonctionnelles du module.
2. Des spécifications existent mais ne suffisent pas à redévelopper le module. Une partie de la connaissance est détenue uniquement par quelques développeurs.
3. Aucune spécification fiable n'existe, et/ou aucun développeur de l'équipe actuelle ne maîtrise le code.

Volonté de restauration à l'identique

1. A redévelopper à l'identique. L'ancien code était propre et parfaitement adapté.
2. A améliorer. Certaines parties de l'ancien code sont réutilisables, mais d'autres doivent être modularisées, améliorées ou réécrites.
3. A réécrire from scratch. La suppression est perçue comme une aubaine qui permet de repartir sur de bonnes bases.

Le produit des deux notes donne une estimation de la dette technique du module.
Du code récent, propre bien documenté aurait vraisemblablement une note globale de 1. Un code plus ancien, relativement réutilisable mais pouvant être amélioré s'en tirerait avec un 4. Enfin, les modules ressentis comme des bombes à retardement écoperaient sûrement d'un 9.

La note obtenue permet de prioriser et de planifier le refactoring des modules, en partant du plus élevé et dans les limites du budget alloué.

Une estimation subjective

Comme pour les estimations Scrum, l'exercice se pratique idéalement avec l'équipe au complet. Le vote individuel permet de mettre en évidence les opinions atypiques (souvent dues à un niveau d'infomation différent) et d'instaurer le dialogue.

Cette méthode ne donne évidemment pas une mesure exacte et universelle de la dette technique ; elle repose entièrement sur l'appréciation subjective de l'équipe. Utilisée en conjonction avec des outils d'analyse de code, elle donne d'excellents résultats pour détecter les zones à risque et fédérer l'équipe autour d'un plan d'action.

Refactorez bien !