BT

Diffuser les Connaissances et l'Innovation dans le Développement Logiciel d'Entreprise

Contribuez

Sujets

Sélectionner votre région

Accueil InfoQ Actualités Utiliser La Métaphore De La Dette Technique Pour Communiquer La Qualité Du Code

Utiliser La Métaphore De La Dette Technique Pour Communiquer La Qualité Du Code

Favoris

La dette technique nous pousse à payer un coût qui augmente peu à peu. A l’origine, la métaphore de la dette technique devait nous aider à parler et à réfléchir sur les décisions et qualités invisibles dans le code. 

Kevlin Henney a prononcé un discours sur les Six Impossible Things à QCon Londres 2022 et pendant le QCon Plus qui s'est tenu du 10 au 20 mai 2022. La Six Impossible Things concernait la dette technique comme étant quantifiable en tant que dette financière :

Nous pouvons quantifier des choses comme le nombre d'éléments de la dette, le temps estimé pour réparer chaque élément, une variété de mesures associées à notre code, telles que la complexité cyclomatique, le degré de duplication, le nombre de lignes de code, etc. Tous ces éléments sont identifiables et dénombrables mais quantifier la quantité de dette financière présente dans le code ne fonctionne pas.

Une métaphore nous donne un vocabulaire et un modèle de raisonnement pour quelque chose qui peut être abstrait et insaisissable, a déclaré Henney. Les métaphores ne sont pas des équivalences ou des identités directes et les traiter littéralement nous ferait passer à côté de l'essentiel.

Certaines décisions sont prises délibérément avec l'idée que nous obtenions un avantage à court terme en choisissant, par exemple, une solution moins générale qui offrirait la possibilité de publier plus tôt ou d’acquérir l’expérience nécessaire de cette fonctionnalité, a déclaré Henney. Cependant, si nous ne parvenons pas à remplacer ou à améliorer cette solution alors que nous supportons les changements qui nécessitent une plus grande généralité, la conception d'origine nous fera prendre du retard. Et nous finirons par payer un coût élevé petit à petit pour ne pas avoir su choisir un meilleur design. C'était le but initial de la métaphore de la dette de Ward Cunningham, a déclaré Henney.

On peut également contracter des dettes sans le vouloir, comme l'a expliqué Henney :

Par exemple, laisser proliférer un code de mauvaise qualité sans surveillance dans notre base de code par négligence technique. Le terme "dette technique" est souvent mal utilisé au point que beaucoup de gens voient dans le code de mauvaise qualité le synonyme de "dette technique". Il s'agit là d'une simplification regrettable car elle souligne la méconnaissance du fonctionnement de la dette financière et, par conséquent, l'une des leçons de la métaphore.  Avoir une dette n'est pas nécessairement un problème et cela ne résulte pas nécessairement de la négligence, mais avoir une dette non gérée qui s'accumule accidentellement et qui n'est pas contrôlée est un problème.

InfoQ a interviewé Kevlin Henney sur la communication de la dette technique.

InfoQ : Vous avez déclaré que “la dette technique” = “le coût de possession de la dette”. Pouvez-vous expliquer comment cela fonctionne ?

Kevlin Henney : Quand on parle de dette technique, nombreuses sont les équipes qui évitent, avec succès, de tomber dans le piège à savoir d'essayer de convertir des métriques de code simple en une valeur monétaire. Par contre, ils se font avoir sur une autre erreur. Une équipe peut passer en revue son code et évaluer tous ses efforts fournis pour traiter les différents éléments de la dette. Cette estimation peut être comptée en heures mais cela peut ensuite – selon l'axiome souvent adopté selon lequel le temps est de l'argent – ​​converti en un chiffre financier.

Il y a deux subtilités sur lesquelles nous devrions être clairs. La première concerne le coût, ce qui est calculé est une estimation du coût et non le coût réel. Nous devrions toujours faire la distinction entre les estimations et les chiffres réels.

La deuxième subtilité touche en plein coeur ce qu’est la métaphore de la dette technique. Si on calcule le coût estimé nécessaire pour régler la dette, on s’aperçoit qu’il existe une hypothèse tacite selon laquelle la dette technique est le coût de la dette à rembourser. Cependant, l’objectif de la métaphore de la dette c’est qu’une dette contractée déclenche des coûts qui vont durer très longtemps et, pendant toute son existence, son coût total sera supérieur au coût à rembourser quelque soit le moment sauf au commencement. La dette technique rapportée au travail supplémentaire qui a été ajouté dans le passé, le présent et l'avenir à cause de  la dette, pas simplement le coût de remboursement du solde actuel. C'est ça le message de la métaphore.

InfoQ : Quels sont vos conseils pour bien employer la métaphore de la dette technique ?

Henney : Quand les développeurs parlent de "dette technique", ils veulent parler de "dette technique non gérée". C'est important de continuer à faire la distinction dans les discussions. 

Rappelons-nous également que la métaphore devait permettre de mieux communiquer. Cela signifie que même si nous respectons la métaphore, ce ne sera pas toujours la meilleure façon de parler de décisions et de qualité de code. Nous pouvons trouver d'autres métaphores plus utiles.

Alors, certes, nous devrions utiliser plus précisément le concept de « dette technique », mais nous ne devons pas l'utiliser comme concept fondateur. Comme l'a observé Émile-Auguste Chartier, « rien n'est plus dangereux qu'une idée quand on n'en a qu'une ».

Au sujet de l’Auteur

Evaluer cet article

Pertinence
Style

Contenu Éducatif

BT