Qu'est-ce que la dette technique ?
La dette technique, aussi appelée dette de code ou dette de conception, est un terme utilisé dans le développement logiciel pour décrire le coût des modifications supplémentaires nécessaires lorsqu'on privilégie une livraison rapide au détriment d'un code propre et efficace, qui prendrait plus de temps à développer. En gros, il s'agit des compromis faits entre la vitesse d'un projet et les bonnes pratiques de codage, qui accumulent une « dette » qu'il faudra « rembourser » avec des intérêts, sous forme de temps, d'argent et de ressources.
La dette technique est un terme large qui englobe une grande variété de problèmes pouvant affecter votre code, allant du code legacy à la documentation manquante ou incomplète, en passant par les bugs, etc.
Le concept est emprunté à la dette financière : on emprunte de l'argent pour acheter quelque chose qu'on veut maintenant, mais qu'on ne peut pas se permettre, et on devra le payer plus tard, avec des intérêts.
On peut soutenir que la dette technique, comme la dette financière, n'est pas forcément une mauvaise chose et peut être utilisée pour faire avancer un projet.
Cependant, il est recommandé d'éliminer la dette technique dès le début d'un projet, car elle crée de l'entropie logicielle si elle n'est pas traitée dans un délai raisonnable.
Considérer la dette technique comme un mal nécessaire pour avancer conduit généralement à une mauvaise priorisation des tâches nécessaires pour la corriger.
Bien que la dette technique puisse parfois accélérer le développement à court terme, elle entraîne souvent des défis qui affectent l'équipe de développement à long terme, notamment une productivité réduite et des reprises de travail importantes.
Lorsqu'une partie du code est modifiée, il est souvent nécessaire de mettre à jour d'autres parties du code ou d'ajuster le code en fonction d'autres zones du code ou de la documentation.
Si ces changements interconnectés ne sont pas pris en compte, la dette technique augmente, ce qui nuit à l'évolutivité et à l'efficacité du projet.
La dette technique en Agile
Dans le développement Agile, la dette technique correspond au coût du retard des tâches essentielles pendant le développement d'un projet logiciel.
Le développement Agile repose sur la vitesse à court terme et sur des fonctionnalités logicielles fonctionnelles en développement continu. La vitesse et la livraison sont prioritaires par rapport à l'assurance qualité et aux meilleures pratiques.
Si la mise en œuvre de sprints rapides avec des délais courts peut accélérer le développement, le code peut ne pas être examiné correctement, ce qui entraîne un code de mauvaise qualité. Souvent, les nouvelles fonctionnalités sont privilégiées par rapport aux corrections de bugs et autres correctifs nécessaires.
Même si l'objectif principal d'Agile est d'accélérer la progression, le manque de correction des bugs finit par ralentir la progression à mesure que les problèmes s'accumulent, créant un mauvais code.
La dette technique en Scrum
En Scrum, comme en Agile, la dette technique correspond au coût implicite du travail ou des reprises lorsqu'on opte pour une solution facile, rapide ou pratique au lieu d'une meilleure approche qui prendrait plus de temps.
Scrum est un cadre de gestion de projet Agile qui vise à structurer et à gérer des équipes, généralement composées d'un Product Owner, d'un Scrum Master et de développeurs ayant des responsabilités différentes.
La structure de Scrum prévoit que l'élimination de la dette technique soit intégrée au sprint suivant.
Il s'agit de contrôler et de rembourser la dette technique afin de maintenir la vélocité et la productivité des développeurs.
Chaque sprint est censé allouer du temps et des ressources à la dette technique, ce qui peut être réalisé en ajoutant des tâches de réduction de la dette technique au backlog afin de s'assurer qu'elles sont prioritaires et traitées par les équipes.
Ne pas gérer la dette technique va à l'encontre des principes Scrum d'adaptabilité et de livrabilité et peut bloquer la progression de l'équipe, rendant le code plus difficile à lire, à maintenir et à étendre.
L'une des questions qui se pose est de savoir qui est responsable de l'identification, de la mesure et du traitement de la dette technique.
Quelles sont les causes de la dette technique ?
La dette technique est généralement causée par des choix de développement logiciel qui ne sont pas à la hauteur des normes recommandées ou nécessaires lors du passage en production. Une certaine dette technique est inévitable, mais elle peut être considérablement réduite en utilisant des revues de code.
Les causes de la dette technique incluent :
- Développement continu : Les entreprises et le code étant en constante évolution, elles fonctionnent sur de longues périodes d'amélioration de projet qui, avec le temps, rendent les anciennes solutions inefficaces.
- Applications modernes : Les applications logicielles modernes incluent généralement plusieurs langages de programmation, frameworks de développement et bibliothèques, entre autres ressources externes. Le support, ou son absence, peut avoir un impact important sur ces applications et leur efficacité.
- Manque de définition : Le développement commence avant la conception. Si vous ne clarifiez pas ou n'établissez pas de référence pour la dette technique, ou si les exigences sont encore en cours d'élaboration pendant le cycle de développement, ce qui a été créé au début peut ne pas correspondre aux besoins à la fin du projet.
- Pression commerciale : Les entreprises subissent une pression constante pour rester à flot, compétitives et prospères. Elles peuvent donc sortir un produit qui n'est pas tout à fait prêt pour être les premières sur le marché. On le voit avec les lancements de sites web et d'applications qui plantent ou présentent des bugs et des problèmes d'utilisation flagrants. La pression commerciale étant constante, la mise à jour et la correction de ces problèmes peuvent rester en permanence dans le backlog de développement.
- Manque de connaissances ou de compréhension techniques : Même les entrepreneurs les plus avertis peuvent ne pas être conscients de la dette technique et des complications qui en découlent lorsqu'ils s'efforcent de sortir des mises à jour en se concentrant sur le produit et les résultats.
- Couplage des modules logiciels : Le degré d'interdépendance entre les fonctions logicielles n'est pas indépendant des modules interchangeables et ne peut pas s'adapter à l'évolution des besoins de l'entreprise.
- Absence de suite de tests ou de validation : Permet des corrections de bugs rapides et dangereuses sans cas de test appropriés pour tester le logiciel et s'assurer qu'il fonctionne comme prévu.
- Manque de collaboration : Les connaissances essentielles sont cloisonnées entre les services, les membres de l'équipe et les individus, ce qui diminue la productivité de l'entreprise en raison d'un manque de communication, de formation et de mentorat.
- Développement simultané : Dans de nombreuses organisations, les équipes de développement peuvent travailler sur différentes branches en même temps, ce qui entraîne un manque de cohésion du code lorsque le produit fini est fusionné dans une seule base de code. Plus la création de code se fait en silos, plus la dette technique augmente.
- Refactoring de code retardé : Le refactoring est le processus d'amélioration de la structure interne du code sans modifier son comportement souhaité. À mesure que les exigences de développement d'un projet évoluent, le code créé précédemment peut devenir obsolète ou difficile à mettre à jour pour les besoins futurs du codage ou de l'entreprise. Plus le refactoring est repoussé, plus la dette technique augmente.
- Absence de normes ou d'alignement clairs : Les meilleures pratiques, les normes, les frameworks logiciels et les technologies existantes ne sont pas respectés. En fin de compte, les normes d'intégration du code seront appliquées et plus l'attente sera longue, plus le coût sera élevé à l'avenir.
- Connaissances insuffisantes des développeurs : Le développeur ne sait pas comment créer et exécuter un code élégant et propre.
- Développeurs externalisés : Lorsque des ressources sont externalisées à des développeurs tiers, l'équipe de développement interne doit parfois refactoriser le code livré.
- Leadership défectueux : La communication des ordres se fait du haut vers le bas et n'est pas clairement pensée ou réfléchie avant d'être exécutée.
- Changements de dernière minute : Le projet est presque terminé et de nouvelles exigences sont fournies avant une échéance serrée, sans temps, ressources ou budget pour tester et analyser les implications des ajustements afin d'apporter les changements appropriés correctement. L'objectif principal est de livrer le produit avec les modifications supplémentaires en espérant que tout fonctionne correctement.
Types de dette technique
Bien qu'il existe une grande variété de types et de définitions de dette technique, on peut les diviser en trois catégories : la dette technique involontaire, intentionnelle et environnementale.
Dette technique intentionnelle:
Décisions délibérées et tactiques prises en connaissance de cause, avec ou sans intention de revenir en arrière et de refactoriser le code. L'entreprise choisit un mauvais code, ou un code « sale », ce qui peut entraîner des risques de sécurité, un code instable, des performances intermittentes ou médiocres, et une mauvaise expérience utilisateur. Bien que ce ne soit pas optimal, la connaissance de ces problèmes permet à l'équipe de les documenter, de les mesurer et de les mettre à jour si nécessaire. Les décideurs ayant une vue d'ensemble de la situation peuvent intentionnellement opter pour des raccourcis ou des solutions imparfaites pour obtenir des résultats rapides. Ces décisions découlent souvent de la nécessité d'une mise sur le marché rapide ou d'autres objectifs immédiats. Elles s'accompagnent toutefois du risque de bugs non identifiés ou de code promu à la hâte, ce qui en fait des bombes à retardement pour votre application.
Dette technique involontaire:
Création inconsciente ou imprévue d'un code médiocre ou bâclé qui est promu en production sans tests ni revue appropriés, souvent sous la pression de délais de livraison stricts. Imaginez cela comme le résultat de bonnes intentions qui ont mal tourné. D'autres facteurs, tels que la complexité accrue d'un projet, peuvent amener les développeurs à introduire par inadvertance des bugs dans leur code. Ces choix de développement, où un code sous-optimal est introduit en production sans retour en arrière immédiat dans l'espoir (ou le pari) de le revoir et de l'améliorer plus tard, peuvent entraîner des problèmes, une sécurité compromise ou des performances médiocres à long terme. Ce type de dette technique est dangereux car certains problèmes peuvent rester inconnus pendant un certain temps. Bien que la conscience de son existence permette aux équipes de la surveiller et de la rectifier, une dette technique involontaire non contrôlée conduit à un logiciel impossible à maintenir.
Dette technique environnementale:
Dette qui a augmenté au fil du temps sans développement actif au sein du code lui-même. Elle est indépendante de la qualité intrinsèque du logiciel ou des intentions des développeurs et s'accumule en raison de facteurs externes. Cela peut être dû à des mises à jour du système d'exploitation qui cassent ou perturbent le fonctionnement du logiciel, à des mises à jour d'API tierces qui rompent la connexion ou à des bibliothèques de code qui introduisent des problèmes pour l'utilisateur. Les mises à jour de sécurité ou les correctifs peuvent empêcher une application de fonctionner correctement. Même si le code original est bon et fonctionne, la dette technique augmentera progressivement au fil du temps. Imaginez une maison construite à la perfection, mais dont l'environnement change au fil du temps, provoquant des changements de fondations ou de la dégradation. Cette métaphore illustre l'essence de la dette technique environnementale : même si une base de code est parfaite au départ, les mises à jour externes peuvent la dégrader.
Les types de dette technique peuvent être subdivisés en fonction de la classification des différenciateurs essentiels, tels que :
- Dette d'architecture : Problèmes d'architecture du produit qui affectent les exigences architecturales. Généralement, cette dette technique résulte de solutions initiales inférieures à l'idéal, compromettant la qualité interne.
- Dette de build : Problèmes qui rendent la tâche de build plus difficile et inutilement longue.
- Dette de code : Problèmes dans le code source (violation des meilleures pratiques ou des règles de codage) qui affectent négativement sa lisibilité et le rendent difficile à maintenir.
- Dette de défauts : Défauts connus, généralement identifiés par des tests ou par l'utilisateur. L'équipe de développement accepte de les corriger, mais la correction est retardée en raison de priorités concurrentes et de ressources limitées.
- Dette de conception : Dette technique découverte en analysant le code source et en identifiant les violations des principes de bonne conception logicielle.
- Dette de documentation : Les développeurs sont trop pressés pour documenter leur code de manière approfondie, il n'y a donc pas de trace documentaire que d'autres développeurs peuvent utiliser pour comprendre leur code.
- Dette d'infrastructure : Problèmes d'infrastructure qui retardent ou entravent les activités de développement. Cette dette technique affecte négativement la capacité de l'équipe à produire un produit de qualité.
- Dette de personnel : Dette créée par des problèmes non résolus de formation ou de répartition du personnel.
- Dette de versioning : Problèmes de versioning du code source, tels que les forks de code inutiles.
- Dette de processus : Processus inefficaces (le processus prévu peut ne pas être approprié).
- Dette d'exigences : Écart entre la spécification optimale des exigences et l'implémentation réelle du système.
- Dette de service : Services web inappropriés qui entraînent une incompatibilité entre les fonctionnalités du service et les exigences de l'application.
- Dette d'automatisation des tests : Travail nécessaire pour automatiser les tests fonctionnels développés pour prendre en charge l'intégration continue et des cycles de développement plus rapides.
- Dette de test : Dette technique encourue lorsque l'équipe commence à passer plus de temps sur la maintenance des tests et moins sur la création de tests pour s'assurer que le logiciel est exempt de bugs.
La dette technique est-elle mauvaise ?
Bien que certains disent qu'elle n'est pas nécessairement mauvaise, il est préférable de ne pas l'accumuler si possible.
Accepter un peu de dette technique à court terme lorsque le temps vous est compté pour la sortie d'un produit peut être justifiable, ou lorsque des mises à jour logicielles vitales doivent être livrées immédiatement.
La dette technique est mauvaise et devient un problème lorsqu'elle est laissée de côté et non corrigée en temps opportun.
Elle s'accumule et finit par se transformer en avalanche.
Cependant, la plupart des dettes techniques produites aujourd'hui sont dues à un code mal écrit.
C'est dommage car aucun développeur ne veut écrire du mauvais code et être inefficace.
La dette technique ne peut être considérée comme bonne que si vous avez l'intention de la rembourser et de l'éliminer complètement.
Tout ce qui sort de ce cadre est vraiment considéré comme mauvais.
Pouvez-vous réduire la dette technique ?
Il existe plusieurs façons proactives de réduire la dette technique.
- Automatiser les tests : Tester manuellement le code pour l'assurance qualité peut prendre du temps et être inefficace. L'utilisation d'outils de test automatisés, comme SonarQube Server, peut réduire ou éliminer la dette technique. L'utilisation de cycles de débogage automatisés et d'autres opérations qui recherchent les problèmes de code chaque fois que le module est mis à jour. SonarQube Server fournit une inspection continue de la qualité du code pour effectuer des revues automatiques avec une analyse statique du code afin de détecter les bugs, les « code smells », les doublons, la couverture et les failles de sécurité dans plusieurs langages de programmation.
- Refactoriser le code source : Le refactoring peut être une autre façon de gérer la dette technique en tirant parti de la qualité du code source tout en laissant le comportement attendu du code inchangé. Le refactoring vise à corriger la mauvaise qualité du code et peut être corrigé avec des outils de test automatisés. Cependant, le manque d'expérience ou l'incompétence peuvent également jouer un rôle, ce qui doit être traité au cas par cas. Une formation ou un enseignement supplémentaire peuvent être nécessaires.
- Utiliser les meilleures pratiques de codage : Les entreprises et les organisations doivent établir des normes de codage internes que les développeurs doivent suivre et exécuter. Lorsque les développeurs sont sur la même longueur d'onde en ce qui concerne les normes et l'étiquette du code, cela contribue à éliminer la dette technique dès le départ.
- Structure du projet : Créer de meilleures structures de projet grâce à des outils de gestion de projet ou surveiller les problèmes de code et les corriger dès que possible dans les projets permettra de réduire la dette. Priorisez les projets et la structure pour soutenir votre calendrier et votre flux de travail.
Comme mentionné précédemment, l'utilisation d'outils de qualité du code, de sécurité et d'analyse peut considérablement réduire la dette technique que vous et votre entreprise devrez gérer ultérieurement.
Comment trouver et gérer la dette technique ?
L'une des meilleures et des plus simples façons de trouver et de gérer la dette technique est d'utiliser des métriques de code comme base de mesure. Il existe de nombreuses méthodes disponibles pour fournir ces données.
Couverture du code : Pourcentage de votre code source qui est testé à un certain degré lorsqu'un programme est exécuté sur des suites de tests spécifiques. Ce sont des règles et des exigences qui doivent être satisfaites par la suite de tests (sous-programmes ou instructions appelés pendant le test). À mesure que du code est ajouté, vous devez vous assurer que la couverture reste constante et ne diminue pas lentement ou significativement.
Complexité cyclomatique : Métrique logicielle quantifiée utilisée pour montrer la complexité d'un programme en analysant les chemins indépendants par rapport au nombre total de lignes de code. Plus il y a de chemins divergents indépendants, plus la complexité cyclomatique est élevée et plus la source est difficile à maintenir.
SQALE-Rating : Méthode permettant d'évaluer la qualité du code source en corrélation directe avec la dette technique du projet. Généralement basée sur une échelle alphabétique de A à E, A étant le meilleur score de qualité.
Violations de règles : Calculées en fonction de l'ensemble de normes de code établi qui sont violées ou enfreintes. Généralement regroupées en catégories en fonction de la gravité de la violation. Bugs : Compter le nombre de bugs dans votre logiciel et surveiller les problèmes critiques est une bonne option pour évaluer la dette technique (plus il y a de bugs, plus la dette technique augmente). Coût du retard : Le « coût du retard » est un cadre qui aide les entreprises à quantifier la valeur économique de la réalisation d'un projet plus tôt que prévu en fonction de la priorisation. L'objectif est de fournir de la transparence sur le temps perdu par les équipes en raison de la dette technique et sur le coût de la réalisation d'un projet plus tôt que prévu.
Conclusion
Bien qu'une certaine dette technique soit inévitable, la plupart peut être évitée. Personne ne veut passer du temps à faire du travail supplémentaire. Prendre les devants avant qu'elle ne devienne un problème est un moyen de s'assurer que vous, vos opérations, votre entreprise et, surtout, votre code sont propres et exempts de dettes.
Bien qu'il existe de nombreux outils sur le marché pour nettoyer et prévenir la dette technique, nous vous encourageons vivement à utiliser notre outil gratuit Lint IDE. Entièrement gratuit et couvrant plusieurs langages de programmation, SonarQube for IDE fournit un retour d'information en temps réel en évaluant plus de 6 000 règles couvrant un large éventail de problèmes.
Il utilise une analyse spécifique au langage pour détecter les bugs, les « code smells » et les failles de sécurité tout en respectant les dernières normes linguistiques.
Cet outil gratuit pour votre IDE contient un large ensemble de règles couvrant la fiabilité, la maintenabilité, la lisibilité, la sécurité, la qualité et bien plus encore. Travaillez plus et retravaillez moins.
Commencez à vous attaquer à votre dette de code dès aujourd'hui pour assurer un avenir durable et productif à vos projets.