Les systèmes logiciels ont tendance à accumuler des ordures - des défauts internes qui rendent difficile la modification et l'extension du système par rapport au code idéal. La dette technique est une métaphore inventée par Ward Cunningham. Elle explique comment percevoir ces ordures, par analogie avec un prêt financier. Les efforts supplémentaires requis pour ajouter de nouvelles fonctionnalités sont les intérêts sur le prêt.



Imaginez que dans ma base de code il y ait un module d'une structure confuse. Besoin d'ajouter une nouvelle fonctionnalité. Si la structure était claire, le travail prendrait quatre jours, mais avec ces ordures, cela prend six jours. La différence en deux jours - c'est l'intérêt sur la dette.

Ce qui m'attire le plus dans la métaphore de la dette, c'est une compréhension claire des coûts de service ou d'élimination. Je peux passer cinq jours à nettoyer la structure modulaire, à retirer les ordures et à payer métaphoriquement le «prêteur». Si je fais cela pour cette fonction, je perdrai parce que je passerai neuf jours au lieu de six. Mais s'il existe deux autres fonctions de ce type, il est plus rentable de retirer les ordures.

Avec cette formulation, la tâche devient purement mathématique. Tout gestionnaire avec une tablette électronique le résoudra. Malheureusement, nous ne pouvons pas mesurer les performances , donc aucun coût n'est objectivement mesurable. Nous pouvons approximativement estimer le temps qu'il faut pour développer la fonction, le temps qu'il faudra pour travailler après avoir retiré les ordures - et assumer le coût de leur suppression. Mais la précision de ces estimations est plutôt faible.

Par conséquent, la meilleure option est généralement de faire ce que nous faisons habituellement avec les dettes financières: payer progressivement le capital. Dans la première fonction, je vais passer quelques jours de plus pour enlever une partie des ordures. Cela peut suffire à réduire les intérêts sur la dette, afin qu’à l’avenir, elle puisse être remboursée en une journée. C'est encore du temps supplémentaire, mais avec l'élimination des ordures, les changements futurs deviennent moins chers. Le grand avantage de l'amélioration progressive est que nous passons naturellement plus de temps à éliminer les déchets dans les zones qui changent fréquemment. Ce sont précisément les zones de la base de code qui ont le plus besoin d'être éliminées.

La comparaison des paiements d'intérêts avec le remboursement de la dette principale permet de déterminer le type de déchets à traiter. Si j'ai une zone particulièrement terrible de la base de code, le problème disparaît s'il s'avère qu'il n'est pas rentable de supprimer les ordures. L'intérêt n'est payé que lorsque vous devez travailler avec cette partie du logiciel (la métaphore est un peu boiteuse à cet endroit car vous devez toujours payer sur un prêt bancaire). Ainsi, des zones de code cauchemardesques mais stables peuvent être laissées seules.

Contrairement aux parties stables du code, les zones d'activité élevée nécessitent une tolérance zéro pour les déchets indésirables, car les paiements d'intérêts y sont extrêmement élevés. Ceci est particulièrement important car les déchets s'accumulent là où les développeurs apportent des modifications sans prêter attention à la qualité: plus il y a de changements, plus le risque de déchets est grand.

Une métaphore de la dette est parfois utilisée pour justifier un code de mauvaise qualité. L'argument est que le code de qualité nécessite plus de temps et d'efforts. Si vous avez un besoin urgent de nouvelles fonctionnalités, il vaut mieux reprendre la dette et la gérer plus tard

Le danger ici est que souvent cette analyse est erronée. La corbeille commence très rapidement à nuire, ralentissant l'introduction de nouvelles fonctionnalités. En conséquence, les développeurs dépassent les limites de crédit et lancent le produit plus tard que s'ils consacraient immédiatement du temps à fournir une meilleure qualité. Ici, la métaphore induit souvent les gens en erreur, car la dynamique de la dette technique ne correspond pas réellement à la dynamique des prêts financiers. En supposant que la dette pour accélérer la sortie du produit ne fonctionne que si vous restez en dessous de la ligne de paiement de la conception dans l' hypothèse de la durabilité de l'architecture , et que les développeurs la franchissent après quelques semaines, pas des mois.



Des débats ont lieu régulièrement sur l'opportunité de considérer différents types de déchets comme une dette. Il me semble qu'il est utile de se demander si un devoir est pris consciemment et raisonnablement - ou de façon imprudente. Un carré de dette technique est donc apparu .

Lectures complémentaires

Autant que je sache, Ward a introduit ce concept pour la première fois dans le rapport OOPSLA de 1992 . Il a également été discuté sur le wiki .

Il y a un enregistrement vidéo où Ward Cunningham discute de sa métaphore.

Dave Nicolette élargit le point de vue de Ward sur la dette technique en fournissant un bel exemple de ce que j'appelle une dette intentionnelle raisonnable .

Plusieurs lecteurs ont suggéré d'autres métaphores valides. David Panarity a qualifié le développement de faible qualité de pénurie de programmation . Apparemment, il a commencé à utiliser ce terme il y a plusieurs années lorsqu'il était conforme à la politique du gouvernement; Je suppose que c'est à nouveau pertinent.

Scott Wood a suggéré de traiter « l'inflation technique comme une perte de sol lorsque le niveau actuel de la technologie dépasse si loin le niveau de votre produit qu'il tombe progressivement hors de l'environnement. Les programmes sont à la traîne dans les versions du langage au point que le code n'est plus compatible avec les principaux compilateurs. "

Steve McConnell a souligné plusieurs bons points dans la métaphore. En particulier, étant donné qu'une réduction de la dette non intentionnelle laisse plus de place pour accepter intentionnellement la dette lorsqu'elle est utile. J'aime aussi sa formulation de paiements minimaux (qui sont trop élevés pour résoudre les problèmes dans les systèmes embarqués, mais pas sur les sites).

Aaron Erickson a parlé du financement d'Enron .

Henrik Kniberg fait valoir que l’ancienne dette technique pose le plus gros problème et qu’il est prudent d’établir un plafond de dette de qualité pour en faciliter la gestion.

Eric Dietrich discute des pertes humaines dues à la dette technique : batailles en équipe, dégradation des compétences et épuisement professionnel.

Modifications

Ce billet a été initialement publié le 1er octobre 2003. Je l'ai complètement réécrit en avril 2019.