Dette technique - Technical debt

La dette technique (également connue sous le nom de dette de conception ou dette de code , mais peut également être liée à d'autres efforts techniques) est un concept de développement logiciel qui reflète le coût implicite de remaniement supplémentaire causé par le choix d'une solution simple (limitée) maintenant au lieu d'utiliser un meilleure approche qui prendrait plus de temps.

Comme pour la dette monétaire , si la dette technique n'est pas remboursée, elle peut accumuler des "intérêts", ce qui rend plus difficile la mise en œuvre des changements. La dette technique non adressée augmente l' entropie du logiciel . À l'instar de la dette monétaire, la dette technique n'est pas nécessairement une mauvaise chose et est parfois (par exemple en tant que preuve de concept) nécessaire pour faire avancer les projets. En revanche, certains experts prétendent que la métaphore de la « dette technique » tend à en minimiser les ramifications, ce qui se traduit par une hiérarchisation insuffisante des travaux nécessaires pour la corriger.

Lorsqu'une modification est lancée sur une base de code, il est souvent nécessaire d'effectuer d'autres modifications coordonnées dans d'autres parties de la base de code ou de la documentation. Les modifications requises qui ne sont pas terminées sont considérées comme une dette et, jusqu'à ce qu'elles soient payées, des intérêts s'ajouteront aux intérêts, ce qui compliquera la construction d'un projet. Bien que le terme soit principalement utilisé dans le développement de logiciels, il peut également être appliqué à d'autres professions.

Causes

Les causes courantes de la dette technique comprennent :

  • Le développement continu, une longue série d'améliorations du projet au fil du temps rendent les anciennes solutions sous-optimales.
  • Définition initiale insuffisante, où les exigences sont encore définies pendant le développement, le développement commence avant toute conception. Ceci est fait pour gagner du temps mais doit souvent être retravaillé plus tard.
  • Les pressions commerciales, lorsque l'entreprise envisage de publier quelque chose plus tôt avant que les changements nécessaires ne soient terminés, accumulent une dette technique impliquant ces changements inachevés.
  • Manque de processus ou de compréhension, où les entreprises sont aveugles au concept de dette technique et prennent des décisions sans tenir compte des implications.
  • Composants étroitement couplés , où les fonctions ne sont pas modulaires , le logiciel n'est pas assez flexible pour s'adapter à l'évolution des besoins métiers.
  • Absence d'une suite de tests , qui encourage les corrections de bogues rapides et risquées .
  • Manque de documentation logicielle , où le code est créé sans documentation à l'appui. Le travail de création de la documentation représente une dette.
  • Manque de collaboration, où les connaissances ne sont pas partagées autour de l'organisation et l'efficacité de l'entreprise en souffre, ou les développeurs juniors ne sont pas correctement encadrés.
  • Le développement parallèle sur plusieurs branches augmente la dette technique en raison du travail requis pour fusionner les modifications en une seule base source. Plus il y a de changements effectués isolément, plus il y a de dettes.
  • Refactorisation retardée ; Au fur et à mesure que les exigences d'un projet évoluent, il peut devenir clair que des parties du code sont devenues inefficaces ou difficiles à modifier et doivent être refactorisées afin de prendre en charge les exigences futures. Plus la refactorisation est longue et plus le code est ajouté, plus la dette est importante.
  • Manque d'alignement sur les normes, où les fonctionnalités, les cadres et les technologies standard de l'industrie sont ignorés. Finalement, l'intégration avec les normes viendra, et le faire plus tôt coûtera moins cher (similaire au "refactoring différé").
  • Manque de connaissances, lorsque le développeur ne sait pas écrire un code élégant.
  • Manque de propriété, lorsque les efforts logiciels externalisés nécessitent une ingénierie interne pour refactoriser ou réécrire le code externalisé.
  • Mauvais leadership technologique, où des commandes mal pensées sont transmises dans la chaîne de commandement.
  • Modifications de spécifications de dernière minute. Ceux-ci ont le potentiel de s'infiltrer tout au long d'un projet, mais le temps ou le budget sont insuffisants pour documenter et tester les changements.

Service ou remboursement de la dette technique

Kenny Rubin utilise les catégories de statut suivantes :

  • Une dette technique survenue : une dette dont l'équipe de développement ignorait l'existence jusqu'à ce qu'elle soit exposée au cours du travail normal sur le produit. Par exemple, l'équipe ajoute une nouvelle fonctionnalité au produit et, ce faisant, elle se rend compte qu'une solution de contournement avait été intégrée au code des années auparavant par quelqu'un qui est parti depuis longtemps.
  • Dette technique connue : dette connue de l'équipe de développement et rendue visible à l'aide de l'une des approches décrites précédemment.
  • Dette technique ciblée : dette connue et dont le service a été ciblé par l'équipe de développement.

Conséquences

Les "paiements d'intérêts" sont causés à la fois par l'entretien local nécessaire et par l'absence d'entretien par d'autres utilisateurs du projet. Le développement continu du projet en amont peut augmenter le coût du « remboursement de la dette » à l'avenir. On rembourse la dette en accomplissant simplement le travail inachevé.

L'accumulation de la dette technique est une cause majeure de non-respect des échéances des projets. Il est difficile d' estimer exactement combien de travail est nécessaire pour rembourser la dette. Pour chaque changement initié, une quantité incertaine de travail inachevé est engagée dans le projet. La date limite est dépassée lorsque le projet se rend compte qu'il y a plus de travail inachevé (dette) qu'il n'y a de temps pour le terminer. Pour avoir des calendriers de publication prévisibles, une équipe de développement doit limiter la quantité de travail en cours afin de conserver la quantité de travail inachevé (ou dette) petit à tout moment.

Si suffisamment de travail est réalisé sur un projet pour ne pas présenter un obstacle à la soumission, alors un projet sera libéré qui porte encore une quantité substantielle de dette technique. Si ce logiciel atteint la production, les risques de mettre en œuvre de futurs refactors qui pourraient remédier à la dette technique augmentent considérablement. La modification du code de production comporte des risques de pannes, de pertes financières réelles et éventuellement de répercussions juridiques si les contrats impliquent des accords de niveau de service (SLA). Pour cette raison, nous pouvons considérer le report de la dette technique à la production presque comme s'il s'agissait d'une augmentation du taux d'intérêt et la seule fois où cela diminue, c'est lorsque les déploiements sont refusés et retirés.

"Comme un programme en évolution est continuellement modifié, sa complexité, reflétant la détérioration de sa structure, augmente à moins que des travaux ne soient faits pour le maintenir ou le réduire."

—  Meir Manny Lehman , 1980

Alors que la loi de Manny Lehman indiquait déjà que les programmes en évolution ajoutent continuellement à leur complexité et à leur structure se détériorant à moins que des travaux ne soient faits pour les maintenir, Ward Cunningham a d' abord établi la comparaison entre la complexité technique et la dette dans un rapport d'expérience de 1992 :

« Envoyer du code pour la première fois, c'est comme s'endetter. Un peu de dette accélère le développement tant qu'elle est remboursée rapidement avec une réécriture... Le danger survient lorsque la dette n'est pas remboursée. Chaque minute passée sur un code pas tout à fait correct compte comme des intérêts sur cette dette. Des organisations d'ingénierie entières peuvent être immobilisées sous le poids de la dette d'une implémentation non consolidée, orientée objet ou autre.

—  Ward Cunningham , 1992

Dans son texte de 2004, Refactoring to Patterns , Joshua Kerievsky présente un argument comparable concernant les coûts associés à la négligence architecturale, qu'il qualifie de « dette de conception ».

Les activités qui pourraient être reportées comprennent la documentation , la rédaction de tests , la prise en charge des commentaires TODO et la gestion des avertissements du compilateur et de l'analyse de code statique . D'autres exemples de dette technique incluent des connaissances qui ne sont pas partagées dans l'organisation et un code trop confus pour être modifié facilement.

Écrivant sur le développement PHP en 2014, Junade Ali a déclaré :

Le coût de ne jamais rembourser cette dette technique est clair ; le coût de livraison des fonctionnalités finira par devenir si lent qu'il est facile pour un produit logiciel concurrent bien conçu de dépasser le logiciel mal conçu en termes de fonctionnalités. D'après mon expérience, un logiciel mal conçu peut également entraîner une main-d'œuvre d'ingénierie plus stressée, entraînant à son tour un taux de désabonnement plus élevé (ce qui à son tour affecte les coûts et la productivité lors de la fourniture de fonctionnalités). De plus, en raison de la complexité d'une base de code donnée, la capacité d'estimer avec précision le travail disparaîtra également. Dans les cas où les agences de développement facturent fonction par fonction, la marge bénéficiaire pour la livraison du code finira par se détériorer.

—  Junade Ali écrit dans Mastering PHP Design Patterns

Grady Booch compare en quoi l'évolution des villes est similaire à l'évolution des systèmes à forte intensité de logiciels et comment le manque de refactorisation peut conduire à une dette technique.

« Le concept de dette technique est essentiel pour comprendre les forces qui pèsent sur les systèmes, car il explique souvent où, comment et pourquoi un système est stressé. Dans les villes, les réparations sur les infrastructures sont souvent retardées et des changements progressifs sont apportés plutôt que des changements audacieux. C'est encore le cas dans les systèmes à forte intensité logicielle. Les utilisateurs subissent les conséquences d'une complexité capricieuse, d'améliorations retardées et de changements incrémentiels insuffisants ; les développeurs qui font évoluer de tels systèmes subissent les fléaux de ne jamais être en mesure d'écrire du code de qualité parce qu'ils sont toujours essayer de rattraper son retard."

—  Grady Booch , 2014

Dans les logiciels open source , reporter l'envoi des modifications locales au projet en amont est une forme de dette technique.

Voir également

Les références

  1. ^ a b Suryanarayana, Girish (novembre 2014). Refactoring pour les odeurs de conception de logiciels (1ère éd.). Morgan Kaufmann. p. 258. ISBN 978-0128013977.
  2. ^ "Définition du terme "Dette technique" (plus, quelques informations générales et une "explication")" . Techopédia . Consulté le 11 août 2016 .
  3. ^ Allman, Eric (mai 2012). "Gestion de la dette technique". Communications de l'ACM . 55 (5) : 50-55. doi : 10.1145/2160718.2160733 .
  4. ^ Jeffries, Ron. « Dette technique – Mauvaise métaphore ou pire métaphore ? » . Archivé de l'original le 11 novembre 2015 . Consulté le 10 novembre 2015 .
  5. ^ Knesek, Doug. « Éviter une crise de la « dette technique » » . Consulté le 7 avril 2016 .
  6. ^ A b c Girish Suryanarayana; Ganesh Samarthyam ; Tushar Sharma (11 novembre 2014). Refactoring pour les odeurs de conception de logiciels : gérer la dette technique . Elsevier Science. p. 3. ISBN 978-0-12-801646-6.
  7. ^ A b c Chris Sterling (10 Décembre 2010). Gestion de la dette logicielle : construire pour un changement inévitable (Adobe Reader) . Addison-Wesley Professionnel. p. 17. ISBN 978-0-321-70055-1.
  8. ^ Rubin, Kenneth (2013), Essential Scrum. Un guide pratique du processus agile le plus populaire , Addison-Wesley, p. 155, ISBN 978-0-13-704329-3
  9. ^ Lehman, MM (1996). "Les lois de l'évolution du logiciel revisitées" . EWSPT '96 Actes du 5e Atelier européen sur la technologie des processus logiciels : 108–124 . Consulté le 19 novembre 2014 .
  10. ^ Ward Cunningham (1992-03-26). "Le système de gestion de portefeuille WyCash" . Récupéré le 2008-09-26 .
  11. ^ Kerievsky, Josué (2004). Refactorisation aux modèles . ISBN 978-0-321-21335-8.
  12. ^ Ali, Junade (septembre 2016). Maîtriser les modèles de conception PHP | Livres PACKT (1 éd.). Birmingham, Angleterre, Royaume-Uni : Packt Publishing Limited. p. 11. ISBN 978-1-78588-713-0. Consulté le 11 décembre 2017 .

Liens externes