Legacy code : quatre étapes pour contrôler et réduire la dette technique
Les projets legacy apportent des défis supplémentaires pour la qualité du code. Ils ont subi de nombreuses modifications (plus ou moins importantes) et ne sont probablement pas maintenus par les auteurs d’origine. Que ça soit par manque d’anticipation à la conception ou une maintenance difficile, ils ont souvent accumulé beaucoup de dette technique. Vous maintenez une telle application et souhaitez maîtriser sa dette ? Vous avez lu « les cinq étapes pour commencer à gérer sa qualité logicielle » mais vous avez eu l’impression de devoir nettoyer les écuries d’Augias ? Je vous propose ici quatre étapes pour reprendre votre dette technique en main.
1. Stabiliser la dette
Cela peut sembler un peu contre-intuitif, mais dans un premier temps il est important de se concentrer sur les développements actuels et non pas sur la correction de ceux du passé. Si on veut pouvoir réduire la dette, il faut d’abord la stabiliser en arrêtant d’en créer. Lors de cette première étape les violations existantes ne sont pas considérées, et il s’agit de ne pas en créer de nouvelles ou de les corriger immédiatement.
Les linters sont très bons à donner un diagnostic sur l’état actuel, mais ils ne suivent pas l’évolution du logiciel. Il faut donc s’appuyer sur des outils comme SonarQube ou Themis. SonarQube est capable d’afficher les changements depuis la dernière analyse ou depuis le début de la période de développement courante. Themis offre un suivi personnalisé et détaillé à chaque développeur et l’avertit des violations qu’il a fait.
En s’appuyant sur ces retours vous pouvez ainsi comprendre la dette qui est créée par vos actions et prendre les mesures nécessaires pour que la courbe de la dette s’inverse. Par exemple, vous pouvez identifier les règles couramment non respectées afin d’y accorder plus d’attention.
2. Fixer des priorités
Une fois la dette stabilisée, vous pouvez commencer à la faire diminuer. Vous ne pourrez pas tout traiter en même temps, il faut donc décider des violations qu’il faut corriger en priorité. La criticité des règles est un facteur important mais il faut bien la différencier de la priorité. La priorité peut aussi être fixée selon la difficulté de correction ou la localisation des violations.
Priorité par règles
La première façon de fixer des priorités est de considérer chaque règle individuellement. Certaines règles seront prioritaires parce qu’elles sont plus critiques. Il est plus important de corriger une potentielle faille de sécurité qu’un problème de formatage du code. D’autres seront prioritaires car elles sont plus simples à corriger. Pour reprendre l’exemple précédent, le code peut-être formaté par des outils, corrigeant ainsi un grand nombre de violations très simplement, tandis que les failles de sécurité peuvent demander une réécriture en profondeur de composants.
L’idéal est de trouver un équilibre, afin de pouvoir progresser rapidement et d’obtenir des résultats tangibles. En commençant par traiter des problèmes trop difficiles vous pouvez rapidement vous décourager devant le manque de changement et la difficulté, mais des corrections mineures pourront sembler peu utiles.
Priorité par composants
Une autre approche consiste à fixer les priorités selon la localisation des violations et non les règles. Un composant mieux connu (par exemple, parce qu’il a été édité récemment) sera plus facile à corriger. Aussi, supprimer complètement les violations d’un fichier ou d’un composant permet d’observer rapidement une progression positive et ainsi rester motivé.
Il est évidemment possible de composer une priorité par composants et une priorité par règles. Ainsi vous pourrez éliminer les violations d’une règle composant par composant, ou à l’inverse éliminer les violations d’un composant règle par règle.
3. Créer des plans d’action
Même avec la meilleure volonté du monde, il peut être difficile de faire un compromis entre nouveaux développements et réduction de la dette technique. Pour permettre à l’équipe de garder en tête les actions à accomplir, Themis propose de créer des plans d’action. Chaque plan correspond à une période de développement (dont la durée est configurable) et peut être affecté à une équipe ou un développeur individuel; il contient une liste d’actions à réaliser (par exemple, un certain nombre de corrections de violations à réaliser pour une règle).
Si vous avez donné la priorité à certains composants, un plan d’action peut ne prendre en compte que les actions réalisées sur certaines parties du code. Vous pouvez donc personnaliser les plans d’actions selon les priorités fixées. Ainsi à chaque période de développement vous pouvez adapter les efforts consacrés à la réduction de dette et les concentrer sur les parties qui en ont le plus besoin.
4. Surveiller les indicateurs
Enfin n’oubliez pas de surveiller les KPIs (Key Performance Indicators), comme le nombre de bugs, de violations, etc. Il est important que vous puissiez observer des effets positifs suite aux efforts consentis, et en fournissant des valeurs qui peuvent être suivies tout au long du développement, les KPIs permettent de s’assurer que la dette est bien réduite. Vous pourrez aussi vérifier l’impact sur les développements courants pour éviter de les ralentir.
Les KPIs vous aideront à ajuster les plans d’action. Si la dette ne recule pas assez vite, vous pouvez créer des plans demandant un effort plus important. Si les efforts de correction empêchent le bon déroulement des autres tâches il est peut-être nécessaire de réduire la voilure en créant des plans d’action plus légers.
Résumé
Maîtriser et réduire la dette technique d’un projet legacy n’est pas une tâche facile, mais en procédant de manière itérative il est possible d’obtenir des résultats. Il est d’abord important de stabiliser la dette, puis de fixer les priorités, afin d’avancer pas à pas. Les plans d’actions vous permettront de mettre en œuvre ces priorités, et les KPIs vous aideront à les équilibrer.