Loading...Comment réduire la dette technique et la dette fonctionnelle ? Où les fonctions inutiles s’accumulent-elles dans votre logiciel ? Pourquoi les supprimer proprement ? C’est ce que je vais vous présenter avec un exemple que j’ai vécu en tant que CTO (Chief Technical Officer).
Définition de la dette technique et identification de la dette fonctionnelle
Dans le premier article de cette série, j’ai défini la notion de dette technique et celle de dette fonctionnelle, ou « Functional Debt », qui est fondamentalement du code bien écrit mais pas terminé ou plus utilisé. A l’inverse de la dette technique, ce code inutile (dette fonctionnelle) n’est pas imputable à un mauvais développement.
Dans le second article sur la dette fonctionnelle, je vous ai donné quelques clés pour identifier les zones de votre application où s’est installée la dette fonctionnelle au fil du temps. Par exemple, discuter avec les utilisateurs est un préalable pour identifier la dette fonctionnelle. Vous collecterez un tas d’informations utiles, voire surprenantes, sur le logiciel existant.
Aujourd’hui je souhaite continuer cette série avec un exemple concret. J’espère qu’il vous aidera à éliminer petit à petit la dette fonctionnelle de vos applications.
Réduire la dette technique de votre logiciel implique, entre autres, de supprimer intégralement les fonctions qui ne sont plus utilisées, et non pas pas uniquement la table ou le point d’entrée. Il faut tirer sur le fil, dé-tricoter votre ouvrage, et supprimer proprement le code inutile. Les CTO de SkillValue vous accompagnent dans l’organisation de vos projets de développement avec des freelances.
Réduire la dette technique en mode agile
Le travail d’équipe commence enfin. Il faut se donner une idée de l’intérêt / du gain pour l’équipe de faire le travail de nettoyage du code inutile. Tout cela doit commencer somme toute assez classiquement par l’ajout d’une User Story dans le backlog pour donner du temps à un membre de l’équipe de l’analyser.
étape 1 : identifier et mesurer la taille de la fonctionnalité à supprimer
Réduire la dette technique et fonctionnelle, c’est d’abord voir le nombre de lignes de code que cela représente. Quels sont les artéfacts à supprimer (tables, classes, etc) ? Quel est le gain potentiel d’allégement de l’application ? Quelle sera l’amélioration de la couverture de code via les tests unitaires ?
Je rappelle qu’il n’existe que deux manières pour augmenter la couverture des tests unitaires à périmètre constant : ajouter des tests ou supprimer du code. La seconde option est souvent négligée ?
Franchement, ce genre d’US (user story) tient facilement dans un sprint de deux semaines. Et suivant la granularité choisie, vous aurez vite fait de faire le tour de votre logiciel. Ou d’avoir identifié les gros gisements de dette fonctionnelle.
étape 2 : confirmer l’obsolescence ou l’inutilité de la fonctionnalité
Lorsque votre PO (product owner) favori propose une fonctionnalité dans le backlog, il prend d’abord soin d’évaluer sa valeur pour le produit. Là, de façon inverse pour réduire la dette, il faut vérifier que personne n’utilise plus la fonction présumée inutile.
Pour ce faire, vous devez vous appuyer sur les éléments à votre disposition. Les logs HTTP, par exemple, vont confirmer ou non que le contrôleur en question n’est jamais appelé ou que la vue n’est jamais rendue.
Si vous êtes sur une appli récente, vous pouvez également mesurer le nombre d’appels sur une API REST. Faites-le sur l’historique dont vous disposez. Vous n’avez pas mis en place de logs http ? Alors votre première US (user story), c’est de les mettre en place. Puis vous remesurez au bout de 3 mois.
Parfois, c’est tout simplement une table qui est vide en PROD alors qu’elle est censée contenir les saisies utilisateur. Ce qui va vous confirmer que franchement personne ne l’utilise.
étape 3 : nettoyer à fond votre code, dès que possible
Vous allez avoir donc 3 cas de figures :
- La fonctionnalité est un vrai succès : elle est utilisée très régulièrement donc finalement c’était un faux positif
- La fonctionnalité n’est pas utilisée du tout : bingo ! Il faut la supprimer : pas uniquement la table ou le point d’entrée mais tirer le fil de la pelote de laine pour la supprimer complètement. Je sais c’est dur mais il faut nettoyer à fond la verrue pour éviter qu’elle ne repousse… ?
- La fonctionnalité n’est pas très utilisée : quelques utilisateurs de-ci de-là voire un seul utilisateur. C’est sans doute ce cas qui vous démoralisera le plus.
Les deux premiers cas de figures sont assez évidents. Mais le troisième cas est sans doute le plus fréquent. Comment faire pour convaincre ces utilisateurs de ne plus utiliser une fonctionnalité ? C’est ce que nous verrons dans notre dernier article !
Pour aller plus loin dans la gestion de la dette d’un logiciel, je vous propose cet article. Même s’il a un focus « Technical Debt », il vous donne des outils et des principes applicables.
Managing Software Debt : http://www.gettingagile.com/2008/10/20/managing-software-debt-article/
Lisez aussi : Gérer la dette technique, c’est bien, mais qui gère la dette fonctionnelle ? Dette fonctionnelle vs. dette technique – Part #2 : comment identifier la “functional debt”
