Dette technique : concept, types et méthodes de résolution

• Concept de dette technique
  • Coût implicite d’un futur retravail, encouru lorsqu’on choisit une solution simple mais limitée au lieu d’une meilleure approche qui demanderait plus de temps
  • Coût de travail supplémentaire généré par le choix de la solution la plus rapide plutôt que de la plus efficace
• Types de dette technique distingués par l’ingénieur logiciel Martin Fowler
  • Dette technique prudente et délibérée (Prudent & Deliberate)
    • L’équipe sait qu’elle contracte une dette, mais évalue si « le bénéfice d’une mise en production plus rapide est supérieur au coût de remboursement de cette dette »
  • Dette technique imprudente et délibérée (Reckless & Deliberate)
    • Résultat d’une décision de faire « vite et salement » alors qu’on connaît les bonnes pratiques de conception et qu’on pourrait les appliquer, mais qu’on n’a pas le temps d’écrire un code propre
  • Dette technique prudente mais involontaire (Prudent & Inadvertent)
    • Résultat du fait qu’on a développé un bon logiciel et un code propre, mais qu’on ne réalise qu’avec le temps « ce qu’aurait dû être la conception »
  • Dette technique imprudente et involontaire (Reckless & Inadvertent)
    • Résultat d’un manque de connaissance
• Méthodes pour traiter la dette technique
  • Gestion d’un inventaire de dette technique
    • Faire une rétrospective du projet pour établir et partager une liste des dettes techniques
    • Chaque fois qu’une dette technique apparaît, consigner le travail nécessaire à sa résolution avec l’effort et le planning estimés
    • Discuter en équipe de l’opportunité et du moment de la résolution, puis définir une stratégie
  • Distinguer la bonne dette technique de la mauvaise
    • Cette distinction aide à prioriser les problèmes les plus importants
  • Refactoring
    • Au fil du travail, remettre en ordre les parties nécessaires et refactorer progressivement
    • Lors d’un refactoring de grande ampleur, partager la situation avec l’équipe et signaler les risques et coûts liés à la dette technique
  • Écriture de tests
    • Plus le code est complexe et plus le refactoring est important, plus il est difficile de modifier le code d’un seul coup sans bug
    • Pour éviter les effets de bord, écrire des tests
  • Définir et respecter des standards de qualité
    • Fixer des standards de qualité pour empêcher la mise en production d’un code bâclé
  • Éviter les changements soudains de règles ou de planning
    • Si les règles concernant les développeurs changent en permanence ou si les échéances bougent, il devient difficile d’éviter la dette technique
    • Fournir un calendrier, une méthodologie et une charge de travail réalistes afin de gérer la dette technique
• La dette technique est-elle toujours mauvaise ?
  • Dans leur livre 『À lire absolument ! Guide d’onboarding des développeurs : naissance d’un développeur professionnel qui comprend le logiciel durable et une culture de collaboration fluide』, Chris Riccomini et Dmitriy Ryaboy écrivent : « si c’est une dette encadrée de manière à ce que l’équipe puisse la résoudre plus tard, on peut la considérer comme une “bonne dette” »
  • But la dette technique peut avoir un impact négatif sur l’entreprise, elle doit donc être traitée
  • Elle peut se manifester par des bugs et dégrader l’expérience utilisateur
  • Quand la dette technique s’aggrave, il devient plus difficile pour les développeurs de travailler dans la base de code existante
  • Le cycle de développement logiciel ralentit, car le temps se divise entre le développement de nouvelles fonctionnalités et la modification des fonctionnalités existantes, ce qui repousse la mise sur le marché