Vivre avec de la dette technique
La qualité d’une application peut être perçue comme un iceberg : il y a ce que l’utilisateur voit que l’on peut appeler la “qualité perçue”, et il y’a sous la ligne de flottaison tout ce qu’il ne voit pas : la “qualité technique”. Une partie trop souvent négligée, volontairement ou non, dans laquelle se cache la dette technique, qui, si elle n’est pas maîtrisée peut mettre en danger les roadmaps produit et démotiver même les plus dévoués développeurs.
L’analogie de la dette technique
Le terme “dette technique” a été inventé en 1992 par Ward Cunningham.
Empruntée au contexte de la finance, elle permet d’exprimer les problèmes de conception et de qualité d’un logiciel.
Le niveau de dette technique d’un logiciel a un impact direct sur la vélocité, et donc le coût de développement d’un logiciel.
En effet, les problèmes de conception et de qualité peuvent limiter l’évolutivité du code et introduire de nombreux bugs et régressions à chaque évolution. Il faut donc plus de temps pour faire évoluer le code (code plus difficile à comprendre et nécessitant des modifications plus importantes, souvent non couvert par des tests automatisés). Ainsi, avec le temps : un logiciel dont la dette technique n’est pas maîtrisée impactera fatalement la vélocité des développeurs et coûtera de plus en plus cher.
L’augmentation des coûts de développement dans le temps pour un périmètre fonctionnel similaire est symptomatique d’un problème de dette technique.
Au delà des problématiques de budget et de TTM, il ne faut pas négliger non plus l’impact moral sur les équipes de développement : travailler sur un projet très endetté techniquement et sur lequel aucune action n’est prise pour adresser le problème n’est ni valorisant, ni motivant : être loin des standards (ne pas progresser), et passer plus de temps sur les corrections que sur les fonctionnalités (souvent dans un contexte de plus en plus tendu) n’incite pas les développeurs à donner le meilleur d’eux-même, voire les pousse à partir (et cela aussi se répercute sur les coûts).
Un projet avec un turnover important des équipes de développement est également symptomatique d’un problème de dette technique.
Deux types de dette
La dette technique est un fléau ! Mais pourquoi en génère-t-on ?
Il y a beaucoup de causes possibles à la dette technique, mais il est possible de regrouper ces causes en 2 catégories : la dette non intentionnelle et la dette intentionnelle.
La dette non intentionnelle résulte de l’introduction de mauvaises pratiques dans le code par manque de normes, de prise de recul sur les décisions relatives à l’architecture du logiciel ou de séniorité dans l’équipe de développement. C’est la plus difficile à maîtriser, car elle est plus difficile à appréhender.
La dette intentionnelle, est, comme son nom l’indique, contractée intentionnellement pour résoudre un problème ponctuel généralement de délai ou de budget. Dans ce cas, la dette est générée par des raccourcis ou “quick wins” pour “emprunter” du temps de développement. Cependant comme tout emprunt : il doit être remboursé par la suite pour ne pas sacrifier la qualité technique du projet sur le long terme (planification d’un sprint dédié par exemple).
Mesurer pour maîtriser
Tous les projets du monde ont de la dette technique ! L’objectif n’est donc pas de tenter de la réduire à néant, mais plus de la maîtriser pour la garder sous contrôle.
Comme il est difficile d’améliorer quelque chose que l’on ne peut pas mesurer, il est important de disposer de quelques indicateurs sur la dette technique le plus tôt possible dans un projet, la réalisation d'un audit technique est fortemment recommandé.
Il n’existe pas de méthode infaillible et universelle pour mesurer la dette, et chacun peut créer son propre indicateur, tant que celui-ci reste le même tout au long du projet.
Il est également possible d’automatiser ce calcul grâce à SonarQube, l’outil standard du marché pour faire de l’analyse statique de code source. Celui-ci se base sur les défauts détectés dans le code et la méthode SQALE pour produire des indicateurs sur la dette technique comme le taux d’endettement et l’estimation du temps pour résorber celle-ci.
Enfin, il est important de noter que la dette technique ne se situe pas uniquement dans le code source, mais également dans tous les éléments techniques qui gravitent autour du projet, à savoir : l’infrastructure et les outils de développement et d’automatisation.
Traiter efficacement la dette existante
Corriger la dette technique existante sur un projet assez gros, ancien et sur lequel aucune analyse de dette n’avait été effectuée auparavant peut se révéler démoralisant à première vue. Cependant, toute la dette existante n’est pas nécessairement à résorber.
En effet, il y’a dans les logiciels du code qui n’évolue pas, le fameux “code legacy” : ancien, non modulaire et sans test unitaire, mais qui a été éprouvé et est considéré comme stable depuis des années. Ce code là ne doit pas être traité : cela induirait des risques et dépenses inutiles sur le projet.
Il peut par contre être intéressant de tenter d’encapsuler ce code et d’en créer une interface propre pour éviter toute contamination avec le code plus propre dans le futur.
Tout comme le code qui n’évolue pas, il est aussi intéressant de regarder la pérennité des modules de code endettés et d’évaluer l’intérêt de traiter la dette sur des modules qui seront abandonnés ou à ré-écrire à court ou moyen terme.
Concernant le traitement de la dette existante, deux pratiques sont à considérer en fonction des objectifs du projet et de l’impact de cette dette.
La première est l’application de la Boy Scout Rule de Robert C. “Uncle Bob” Martin qui consiste à nettoyer la dette existante sur chaque fichier source que l’on est amené à modifier dans le cadre de la maintenance ou de l’évolution du logiciel (et si possible écrire les tests unitaires manquants).
“Leave your code better than you found it” — Boy Scout Rule — Robert C. “Uncle Bob” Martin
Cette règle, si elle est appliquée par toute l’équipe, permettra de corriger la dette en continu.
La deuxième pratique est la mise en place d’une campagne de nettoyage, c’est à dire un temps dédié à la résorption de la dette sur un ou plusieurs modules de code prioritaires. C’est une tâche ingrate et fastidieuse, mais qui se révèle nécessaire quand l’impact de la dette devient trop important pour assurer le bon déroulement du projet.
Un outil comme SonarQube permet d’aider à mener à bien ce type de campagne grâce à la classification (par sévérité et catégories) et au suivi (affectation, validation des corrections) des anomalies.
Contenir la dette
Que ce soit au démarrage du projet, ou suite à une campagne de résorption de la dette, il faut à tout prix éviter de tomber dans ce que j’appelle le phénomène du “range ta chambre” (vous comprendrez si vous avez des enfants), c’est à dire : laisser de la nouvelle dette technique s’accumuler sans contrôle !
Pour cela, il est nécessaire de mettre en place (ou de s’assurer de la bonne application de celles-ci, si elles sont déjà en place) un certain nombre de règles et normes, dont voici les principales :
- Définir des normes de développement : la rédaction de style guides, guides de bonnes pratiques, fichiers README et autres documentations qui permettront de définir des standards et de faciliter l’onboarding de nouveaux développeurs sur le projet.
- Introduire des pratiques favorisant le code de qualité : Test Driven Development (TDD), pair programming, revue de code…
- Mettre en place des surveillances automatisées : tests sur une plateforme d’Intégration Continue, analyse statique du code…
Nos recommandations
La dette technique est un phénomène inhérent au développement logiciel : il y en a partout ! Elle a un impact sur le coût de développement d’un logiciel à moyen et long terme : l’ignorer est une erreur.
Chez inside|app, nous recommandons :
- De définir des indicateurs fiables pour mesurer la dette, mais surtout de suivre son évolution dans le temps.
- De trouver le bon équilibre entre maintenabilité et sur-investissement, en acceptant le maintien d’une partie de la dette (code ancien, ou amené à évoluer ou disparaître prochainement).
- D’instaurer des normes et pratiques de développement pour assurer un niveau de qualité conforme aux aux attentes du projet ou de l’organisation.
- De faire de la maîtrise de la dette technique un outil de motivation / challenge pour les développeurs en s’appuyant sur des outils de mesure et feedbacks quotidiens ainsi que sur des mécanismes de gamification (avec l’outil Quboo par exemple).