LaDetteTechnique:PourquoietCommentlaRéduire?

La dette technique est un concept qui désigne l'accumulation de travaux non effectués ou mal effectués dans un projet informatique.
Elle peut être causée par de nombreux facteurs, tels que le manque de temps donné aux équipes de développement pour implémenter le produit, le manque de budget ou de ressources, ou encore la mauvaise planification.

La dette technique peut avoir de graves conséquences sur la qualité et la maintenabilité d'un projet informatique. En effet, en laissant de côté certains travaux ou en les réalisant de manière inadéquate, on peut créer des bugs, des failles de sécurité ou des problèmes de performance. Ces problèmes peuvent être coûteux à corriger et peuvent entraîner des retards et des coûts supplémentaires.

Qu'on le veuille où non, la dette technique est présente et indissociable de tout projet. Il est donc important de savoir la mesurer tout au long du projet et d'apprendre à la gérer.

En tant qu'agence de développement web et mobile, Blacksmith est régulièrement amené à travailler sur la qualité de code, sa maintenabilité et essaie de minimiser la dette technique des projets sur lesquels ses développeurs travaillent.

Nous allons voir ensemble dans cet article comment mesurer et diminuer cette dette technique.

Nous avons vu plus haut ce qu'était la dette technique, voyons maintenant comment nous pouvons la mesurer et la réduire.

Comme disait le "pape du management" Peter Drucker : "If you can't measure it you can't improve it.", où dans la langue de Molière : "Si on ne peut pas le mesurer, on ne peut pas l'améliorer".

Avant de penser à réduire la dette technique d'un projet, il faut pouvoir évaluer son ampleur pour prendre les bonnes décisions afin de la réduire efficacement.

S'il existe plusieurs méthodes pour mesurer la dette technique dans un projet informatique, voici les principales :

1. Analyse de code 🔎 : il est possible de mesurer la dette technique en analysant le code source du projet. On peut utiliser des outils d'analyse de code pour détecter les parties du code qui sont obsolètes, mal documentées, peu lisibles ou sujettes aux erreurs. Ces parties du code représentent souvent une dette technique importante.

2. Tests automatisés 🤖: la mise en place de tests automatisés peut aider à mesurer la dette technique en détectant les erreurs et les bugs présents dans le code. Plus il y a de tests automatisés et plus ils couvrent de parties du code (code coverage), plus la dette technique sera facilement identifiable. Chez Blackmith nous utilisons par exemple Jest, le framework de test en JavaScript créé par Facebook.

3. Suivi de la qualité du code (code quality) : il est possible de suivre la qualité du code en utilisant des indicateurs tels que le taux de couverture de code, le nombre de commits, le nombre de révisions de code ou encore le nombre de bugs détectés. Ces indicateurs peuvent aider à mesurer l'état de la dette technique dans le projet.

4. Évaluation des risques : la dette technique peut être mesurée en évaluant les risques associés au projet. Par exemple, si le projet comporte de nombreuses parties de code obsolètes ou mal documentées, cela peut représenter un risque important pour la qualité et la maintenance du projet.

Certains outils existent pour automatiser ces mesures, Sonarqube permet par exemple de détecter, classifier et résoudre des défauts dans le code source.
Le logiciel permet notamment d'identifier les duplications de code, de mesurer le niveau de documentation et de connaître la couverture de test déployée.

Voici quelques conseils pour réduire la dette technique de son projet digital :

1. Mettre en place une gestion de projet efficace : une bonne gestion de projet permet de planifier les tâches et les ressources de manière adéquate, ce qui peut aider à réduire la dette technique.

2. Allouer suffisamment de temps et de ressources aux tâches : en allouant suffisamment de temps et de ressources aux tâches à accomplir, on peut éviter de laisser des travaux en suspens ou de les réaliser de manière inadéquate.

3. Écrire du code de qualité : en veillant à écrire du code de qualité, on peut réduire les risques de bugs et de problèmes de performance, et donc la dette technique.
Comment améliorer sa code quality ? En mettant par exemple en place des normes de codage (par exemple les normes KISS, DRY, SOLID...), en utilisant des outils automatisés vérifiant la qualité de code (eslint, SonarQube...), sa lisibilité (via un formateur ou logiciels "code formatters") et en faisant relire régulièrement son code par un développeur plus senior (par exemple en utilisant le workflow "git flow" couplé avec un système de "pull requests") après implémentation d'une fonctionnalité.
En fonction du temps qu'on peut y consacrer, la revue de code peut permettre de vérifier la qualité de code, sa lisibilité et sa robustesse, mais aussi :

• de vérifier ses performances

• de faire de la validation fonctionnelle avec des tests appropriés pour tester la cohérence du produit et vérifier que ce qui a été développé réponde aux attentes décrites dans la user story liée où le cahier des charges

• de faire de la revue graphique pour valider que le développement correspond aux maquettes et respecte ainsi l'expérience utilisateur prévue.

Qu'il s'agisse d'applications web, applications mobiles, ou encore de sites vitrine, développements d'APIs ou d'un script d'import de base de données... tout code peut être revu en vue de l'améliorer pour le rendre plus efficace, plus facile à maintenir et éviter qu'il engendre des anomalies sur le long terme.

4. Mettre en place des tests automatisés : la mise en place de tests automatisés (par

exemple des Tests Unitaires Automatisés) peut aider à détecter les erreurs et les bugs présents dans le code, et donc à réduire la dette technique.
C'est ce qui est par exemple fait dans un projet agile utilisant la méthodologie de développement TDD (pour Test Driven Development), où les tests sont écrits avant d'écrire le code à tester, cela afin de valider les fonctionnalités et les principaux scénarios (scénario de test nominal et scénarii alternatifs) à développer.
Il peut s'agir à la fois de tests au niveau du code source, mais également de la rédaction (en partant de la specification ou du cahier des charges) de cahier de tests manuels qui sera exécuté un testeur Assurance-Qualité (QA).
Il est également courant de créer des données de test permettant de valider la manipulation de données, tester le comportement global du produit à un stade où celui-ci est encore en construction.
L'écriture des tests et leur automatisation peut représenter un certain temps de travail, il faut donc penser à l'anticiper dans le planning du projet.
On peut également créer des campagnes de test en utilisant un logiciel de test comme Sélénium (ou d'autres frameworks comme Cypress, JMeter, WebdriverIO, Espresso ou Squash tm) permettant de simuler des comportements d'utilisateurs (notamment via des scripts), mais on peut aussi faire faire des tests manuels par des testeurs (attention, le testeur doit idéalement être différent de la personne qui a codé le produit) qui suivront un plan de test et remonteront pendant la phase de recette, les anomalies du produit avec le scénario de reproduction et des captures d'écran.
Enfin, si on souhaite tester la scalabilité et la robustesse du produit et de son architecture, on peut exécuter des tests de charge pour simuler une utilisation intensive du produit sans avoir à la reproduire manuellement avec des milliers de machines et de testeur 😅.
Il est important d'effectuer des tests avant et après la mise en production pour vous assurer que la mise à jour apporte son lots d'améliorations et fixes sans entraîner de régressions.

5. Refactoriser le code : la refactorisation du code consiste à le réorganiser ou à le réécrire de manière à le rendre plus lisible (par exemple en réduisant le nombre de lignes de code par fichier), maintenable et performant.
On va par exemple réduire le nombre de lignes de code par fichier.
La refactorisation peut être faite à un moment défini dans le projet, ou tout au long du projet suite aux revues de code permettant de valider un certain niveau de qualité du code avant d'intégrer le code revu à la code base.
Cette pratique de refactoring permettra d'aider à réduire la dette technique.

6. Suivre l'état de la dette technique : en suivant régulièrement l'état de la dette technique, on peut identifier les parties du code qui nécessitent une attention particulière et prendre des mesures pour les corriger. On peut mesurer la qualité de code en utilisant des logiciels de qualimétrie tels que SonarQube (anciennement Sonar).

Il est important de noter que la réduction de la dette technique nécessite souvent du temps et des ressources.
Il est donc important de planifier ces efforts de manière adéquate et de les prioriser en fonction des risques et des enjeux du projet.

A noter que le choix de la méthodologie de projet peut avoir des conséquences sur la gestion de dette technique : la méthodologie agile "Extreme Programming" est par exemple très vigilante sur le sujet et prévoit des pratiques telles que le "pair programming" qui permettent de conserver une bonne qualité de code.

Pour résumer ce que nous avons vu dans cet article :

• la dette technique est un phénomène courant dans les projets informatiques, qui peut avoir des conséquences graves sur la qualité et la maintenabilité d'un projet

• Il est important de mettre en place des processus de gestion de projet efficaces et de suivre régulièrement l'état de la dette technique afin de la prévenir et de la réduire

• On peut résorber la dette technique de son projet web en allouant du temps et des ressources sur les tâches de refactoring de code, revue de code (par exemple avec des reviews de "pull requests") ou encore en augmentant la part de code couvert par des tests automatisés tels que des tests fonctionnels, tests unitaires et d'intégration ou encore de tests de non régression qui devront être exécutés avec succès lors d'un processus d'intégration continue / déploiement continu visant à déployer une nouvelle version du produit sur un environnement de test, pre-production ou production.

En suivant ces recommandations, vous devriez pouvoir mesurer et réduire la dette technique de vos projets agiles ou classiques !

Ne sous-estimez pas les risques que peuvent entraîner une forte dette technique sur vos projets.
Au moment d'écrire les tests, de refactoriser son code ou de faire des codes reviews, on peut penser que le retour sur investissement ne sera pas forcément là, mais en réalité, il s'agit d'un investissement qui restera tout le long du cycle de vie de votre produit, et lui assurera une plus grande stabilité, robustesse, et maintenabilité.
N'attendez pas qu'un bug critique plante votre site et vous coûte du chiffre d'affaires 😉

Besoin de reprendre un code source difficile à maintenir pour remettre de la qualité et des bonnes pratiques en place ? Contactez-nous à partners@blacksmith.studio !