19 Novembre 2017

La dette technique d'un projet Drupal, comment la mesurer... Et la maîtriser !

Commentaires

Un projet ne peut pas être à la fois rapidement réalisé, de bonne qualité et pas cher. Les chefs de projets sont souvent confrontés à ce dilemme et ce sont les leviers suivants qui permettent de trancher la décision : qualité, budget et délais d’exécution. Retour sur les signes permettant de déceler la dette technique et les moyens de la maîtriser.

Centre de services, TMA, demandes d'évolution... Nous reprenons régulièrement des projets que nous n'avons pas développés. Méfiants - et curieux à la fois - nous conseillons et imposons même parfois un audit technique et la documentation du site pour valider ou non la faisabilité de notre intervention. Il est cependant difficile de déceler certaines erreurs ou exotismes de conception sans entrer dans le vif des interventions de maintenance... Chaque projet, résultat des exigences et d'un historique différent expose plus ou moins de difficultés, et parfois de malfaçons. Lorsque nous sommes confrontés à ce type de "surprises", comment collaborer avec nos clients pour aboutir à des prises en charge équilibrées... C'est toute la problématique de la dette technique, qui affecte aussi les projets Drupal, par des erreurs de conception, de choix de modules ou de développements sur-mesure...

Un code fragile peut présenter des failles et se détériorer avec le temps. C’est un constat à ne pas prendre à la légère car un mauvais code peut engendrer des investissements supplémentaires qu’il est possible de réduire... En anticipant. Ce phénomène est appelé la dette technique, un sujet dont on entend peu parler mais qui peut s’accroître de manière exponentielle si l’on s’en préoccupe pas. Dans ce post nous souahitons identifier la dette technique et maîtriser ce phénomène.

Qu’est ce que la dette technique ?

Un projet ne peut pas être à la fois rapidement réalisé, de bonne qualité et pas cher. Les chefs de projets sont souvent confrontés à ce dilemme et ce sont les leviers suivants qui permettent de trancher la décision : qualité, budget et délais d’exécution. En effet, trois solutions sont envisageables dans la réalisation d’un projet :

  • Réaliser un projet rapidement avec une qualité élevée : cela nécessite certainement un budget plus conséquent. Le projet coûtera donc cher.
  • Réaliser un projet lentement avec une qualité élevé : la réalisation du projet prendra beaucoup plus de temps. Cependant, avec l’évolution imprévisible et véloce du web, les fonctionnalités initialement prévues risquent de ne plus correspondre aux besoins et aux standards actuels.
  • Réaliser un projet rapidement avec un budget limité : le produit sera livré rapidement et à moindre coût mais au détriment de la qualité du code initialement prévue. 

Etant donné que le budget est souvent le paramètre qui est difficilement négociable, le choix se joue entre la qualité et  la rapidité. Ce qui signifie qu’il faut choisir entre assurer un certain niveau de qualité au risque de prendre du retard sur les fonctionnalités ou avancer le plus rapidement au risque de livrer un produit avec des défauts. C’est souvent la seconde option qui est choisie. Le produit perd de sa qualité, on dit même qu’il présente un déficit de qualité dans le code : c’est ce qu’on appelle la dette technique.

Ainsi, la dette technique peut être définie comme l’accumulation du temps de développement nécessaire pour corriger le déficit de la qualité du code (débogage, maintenance, redéveloppement de certains morceaux de code ou de fonctionnalités entières, etc.) D’ailleurs, Ward Cunningham s’est inspiré de la dette financière que l’on retrouve dans le financement des entreprises pour aborder le problème de la dette technique, en raison des similitudes des deux concepts. Selon lui, un code de qualité inférieure implique inévitablement des investissements supplémentaires pour rectifier le niveau de qualité du code. Cela peut être comparé à une dette financière avec des intérêts : la dette étant le déficit de la qualité du code et les intérêts représentant les coûts supplémentaires qui devront être payés dans le futur.

Les signes d’une dette technique

En partant du principe que le code n’est pas parfait, qu’il ne reste pas indéfiniment parfait et qu’il nécessite de le maintenir : si vous avez du code, vous avez forcément de la dette technique. Plus le code sera mauvais, plus il sera difficile de le maintenir et de le faire évoluer et donc plus votre dette technique sera importante.

Il convient de rester vigilant sur certains signes annonciateurs d’une dette technique et notamment si vous entendez des affirmations telles que «  On ne touche pas à cette partie sinon ça va casser » ou « On attend l’intervention de X pour changer ce morceau de code ». Cependant, certains signes sont plus alarmants que d’autres :

  • La difficulté à faire évoluer les fonctionnalités ;
  • Chaque évolution nécessite des études d’impact fort ;
  • Les bugs à répétition ;
  • La dépendance de l’équipe à des rôles spécialistes ;
  • Le nombre d’heures supplémentaires effectuées par les développeurs ;
  • L’obsolescence de certaines librairies ou modules qui ne reçoivent plus de mises à jour ;
  • Le besoin en formation et outils ;
  • L’insatisfaction des utilisateurs lors des livraisons ;
  • Etc.

Ces signes annonciateurs permettent de déduire que l’ombre d’une dette technique plane. Il convient alors de l’identifier et la mesurer pour mettre en place une solution de traitement efficace.

Identifier et mesurer la dette technique

Un des principaux problèmes de la dette technique est qu’elle n’est pas évidente à identifier, contrairement à une dette financière qui est facilement calculable. C’est pourquoi certains n’ont en pas connaissance ou du moins n’en mesurent pas la gravité. On ne peut pas savoir exactement le taux de dette technique à son actif mais on peut mettre en place des moyens de mesure pour évaluer son importance.

Tout d’abord, il convient d’identifier si la dette technique est volontaire ou involontaire. La différence est la suivante :

  • La dette technique volontaire - Lorsqu’elle est volontaire,  il est plus facile d’en prendre conscience puisque c’est un choix stratégique. La décision choisie est de livrer du code tout en sachant qu’il comporte des défauts, afin de respecter les impératifs du time-to-market. Cette manière de procéder permet de livrer des nouvelles fonctionnalités pour en profiter le plus rapidement bien qu’elles présentent une qualité de code médiocre ou des bugs. Ainsi, la dette technique est un risque à prendre qui favorise l’innovation dans certains cas, ce qui constitue un grand avantage.
  • La dette technique involontaire - En général, c’est une dette qu’on a du mal à voir et qui se développe à notre insu.  Plus un projet devient complexe et avec des intervenants différents et des expériences différentes, plus la dette technique est disposée à grandir. La dette technique peut résulter alors d’un manquement dans le respect des bonnes pratiques pour coder, dans le « camouflage » ou le contournement des dysfonctionnements en mettant en place des corrections fragiles, dans l’application de méthodes trop longues et complexes, dans le manque de documentation du code… dégradant silencieusement la qualité du code.

Que la dette technique soit volontaire ou involontaire, il est nécessaire de mettre en place des indicateurs pour mesurer et maîtriser cette dernière. Plusieurs types de solutions sont possibles, notamment :

  • Les outils de mesure automatique : c’est une solution intéressante pour commencer à mesurer sans effort le niveau de la dette technique notamment grâce à des outils qui décèlent des violations des bonnes pratiques. Par exemple l’outil Sonar permet de s’assurer que les développeurs suivent des métriques concernant les classes et les méthodes.
  • Les outils de mesure de couverture de tests : ce type de solution permet de connaître la quantité de code couverte par les tests automatiques. Par exemple, une couverture inférieure à 75% peut indiquer d’importants problèmes dans le code.
  • Les outils de mesure manuelle : les indicateurs de mesure automatique ne représentent qu'un élément dans la mesure de la dette technique. Vous pouvez vous constituer des rapports pour mesurer l’impact de la dette technique avec certains indicateurs plus révélateurs tels que le nombre de bugs sur une période donnée et par application, la durée des investigations sur un produit, un composant ou un code hérités, le taux d’insatisfaction lors des livraisons, etc.

Maîtriser sa dette technique

Les indicateurs de mesures permettent d’évaluer de manière concrète le niveau d’impact de la dette technique selon certains facteurs, c’est en quelques sortes un état des lieux. Il convient à présent de mettre en place des solutions pour maîtriser sa dette. Pour cela, il n’y a pas de science exacte, mais il est possible de s’orienter vers certains moyens de gestion qui aideront à diminuer la dette :

  • Réaliser un backlog technique : il s’agit de lister toutes les tâches techniques à réaliser en précisant la description de l’intervention, dans quelle partie du code le changement doit s’opérer et  l’importance de la tâche. La priorisation des tâches est très importante, car certaines tâches sont beaucoup urgentes et donc plus « actrices » de la dette technique. D’autant plus qu’il est inutile de corriger intégralement le code sachant que certains morceaux de code sont inutilisés ou ne présentent pas de défauts. Le backlog peut être utilisé dès le début d’un projet pour avoir une vision d’ensemble de chaque tâche, de leur importance et de leur estimation. En plus d’aider à mieux gérer une dette existante, cet exercice est un bon moyen de prévention de la dette technique.
  • Estimer le travail en fonction de la dette technique : lorsqu’une nouvelle demande doit être implémentée dans un code de qualité inférieure, cette implémentation nécessite probablement de retravailler le code (la refactorisation). Ce travail supplémentaire demande un budget supplémentaire, il faut donc le prévoir. Il est recommandé d’inclure le budget de refactorisation dans l’estimation de la nouvelle fonctionnalité, ainsi on évite d’alourdir la dette technique en travaillant sur une parcelle de code défaillant. Cependant, une réflexion en amont est indispensable pour vérifier l’impact de la nouvelle fonctionnalité et d’en conclure si le travail de refactorisation est nécessaire ou non.
  • Prévoir des versions de nettoyage pour des refactorisations plus conséquentes : il est possible de déployer des versions dédiées pour le nettoyage du code et retravailler l’architecture si le besoin se présente. Une version dédiée permet de procéder à des modifications ou des améliorations plus importantes.  Il faut cependant rester vigilant à ne pas perdre du temps et donc de l’argent avec des refactorisations inutiles. Cette méthode n’est pertinente que si l’on a dressé une liste de tâches à traiter selon le niveau d’urgence. 
  • Créer une tâche tampon qui servira pour la refactorisation : cette astuce rejoint les deux autres points mentionnés ci-dessus. Il s’agit de fixer un pourcentage de temps (et donc de l’argent) pour des interventions diverses non planifiées comme le débogage. Ainsi, il est possible d’utiliser ce temps alloué à cette tâche pour de la refactorisation non prévue. Le temps étant prédéfini, il n’y a donc pas de mauvaises surprises concernant le budget. Cette initiative permet de gérer la dette technique de manière récurrente.

Ce ne sont ici que des exemples d’actions pour réduire la dette technique, il est possible de les mettre en place seules ou de manière combinée selon la criticité de la dette technique.

Payer la dette technique : comment ça marche ?

A la différence d’une dette financière, il n’est pas obligatoire de rembourser la dette technique dans certains cas. En effet, tout le code n’a pas à être parfait : il y a des composants plus importants que d’autres. Eric Evans aborde cette vision sous le concept de Design Stratégique. Il considère que l’on ne peut pas avoir le même niveau de qualité dans chaque composant d’un produit : il y a des parcelles de code qui ne sont pas amenées à évoluer ou qui n’implémentent pas de fonctionnalités majeures. Même si le code n’est pas de qualité élevée, le travail de refactorisation ici est inutile voire « superflu ». Vous avez bien de la dette technique, mais son impact est si faible voire nulle qu’il n’est pas nécessaire de la traiter. Le Design Stratégique permet de gérer la dette technique de manière raisonnable : il ne faut pas perdre de vue l’efficience.

Cependant, dans d’autres cas, payer la dette technique ou les intérêts est inévitable. Franck Bushmann a décrit trois possibilités pour « rembourser » la dette technique :

  • Payer la dette technique : cela signifie qu’il faut débloquer un budget pour retravailler ou remplacer le code.
  • Convertir la dette technique : il s’agit de remplacer la solution actuelle défaillante ou obsolète avec une autre solution correcte mais qui est loin d’être parfaite. Ainsi, votre taux d’intérêt avec la nouvelle solution est inférieur.
  • Payer seulement les taux d’intérêt : cette option implique de garder le code défaillant et de continuer à vivre avec les contraintes (code très peu flexible, difficilement évolutif, bugs à répétition, obsolescence de certains composants, etc.). Quoiqu’il en soit, cette stratégie implique également le paiement de la dette mais avec un taux d’intérêt plus ou moins élevé et instable ce qui est peu rassurant sur une vision de long terme.

Conclusion

La dette technique est une problématique difficilement perceptible mais bien réelle. Sa croissance est étroitement liée à la méconnaissance de ce phénomène. Plus vous prenez conscience de l’état de votre dette technique et de son impact, plus il est facile de la maîtriser et de réduire les conséquences. Réaliser des projets rapidement et à moindre coût impactera forcément la qualité du produit. D’autant plus que la dette technique est inévitable : si vous avez du code, vous avez de la dette technique ! En effet, tout code demande inéluctablement de la maintenance de sécurité, de la correction de bugs et de l’évolutivité. Même si la dette technique est liée à la qualité du code, nous avons vu que le code de chaque composant n’a pas à être parfait et qu’il convient de prioriser les tâches à faire selon leur impact. De plus, la dette technique peut présenter des bons côtés. En effet, lorqu'elle est volontaire, elle favorise l’implémentation rapide de fonctionnalités nouvelles voire innovantes (un peu à la manière des modules expérimentaux de Drupal 8). La dette devient alors un investissement, mais qui convient de surveiller de très près avec des objectifs et des indicateurs de mesures.

Et la reprise des projets dont vous n'êtes pas responsables ?

Autant dire, que dans ce cas, soit il est possible d'anticiper un budget de refactorisation... Soit il va falloir beaucoup de confiance avec votre client pour lui expliquer et lui faire accepter les échecs de conceptions optimisées ! Mais nul doute que "ce qui s'énonce clairement se comprend aisément" ! Enfin dans la plupart des cas...

Article synthétisé par @Myriam et l'équipe de @bluedrop_drupal - Photo @chdugue - https://twitter.com/chdugue