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 La Dette Technique Est Quantifiable En Tant Que Dette Financière : Impossible Pour Les Développeurs

La Dette Technique Est Quantifiable En Tant Que Dette Financière : Impossible Pour Les Développeurs

La dette technique peut être quantifiée de plusieurs manières mais pas la dette financière associée. Selon Kevlin Henney, on peut quantifier une certaine quantité de dette technique, estimer le temps pour réparer chaque élément de la dette, analyser une série de métriques associées au code telle 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 évaluer la quantité de dette financière présente dans le code ne fonctionne pas. 

Henney a prononcé un discours sur les Six Impossible Things à Londres lors de la QCon 2022 et de la QCon Plus en mai 2022 du 10 au 20.

Beaucoup d'éléments de la dette technique peuvent être quantifiés. Selon Henney nous pouvons répertorier et numéroter les problèmes spécifiques à l'intérieur du code et si nous prenons conscience de manière intentionnelle de la dette technique telle qu'elle a été initiallement introduite, nous pouvons retracer toutes les décisions que nous avons prises y compris les implémentations qui sont à revoir. Si nous nous concentrons sur la dette involontaire, nous pouvons examiner toute une gamme de métriques sur la qualité du code.

Il y a beaucoup de choses que nous pouvons quantifier en matière de dette technique mais la dette financière associée n'en fait pas partie, comme l'a expliqué Henney :

Le fait de pouvoir exécuter une analyse statique sur le code et d'en sortir une valeur monétaire correspondant à une traduction précise de la dette technique en une dette financière est à la fois une profonde incompréhension de la métaphore - et du fonctionnement des métaphores - et invraisemblable.

Selon Henney, quantifier le nombre de dette financière dans le code ne fonctionne pas. Nous avons besoin, tout au moins, d'une fonction de conversion marquante qui intègrerait une sorte de concept. Par exemple, "pourcentage de code dupliqué" ou "accès à la base de données non configurable" que l'on pourrait traduire par euros et cents :

Quelle est la valeur de la dette correspondant à "l'accès à la base de données non configurable" ? Quelle est la valeur de la dette de votre achitecture basée sur un framework tiers par rapport à un autre ? Quelle est la valeur de la dette d'une décision qui peut (ou non) avoir des avantages à court terme mais nécessitera (probablement) une mise à jour à long terme ? La question est tellement abstraite et malléable qu'essayer d'obtenir un chiffre financier semble non seulement prématuré mais relève de la mauvaise science.

Pour Henney, ce n'est pas parce que nous pouvons transformer quelque chose, une métrique de code par exemple, que nous pouvons le changer en quelque chose d'autre comme de l'argent :

 

Une valeur financière n'a pas plus de rapport significative que peut avoir la valeur RGB de mes yeux avec ma taille.

Même si nous sommes d'accord pour dire que la duplication excessive de code représente une odeur de code, ça ne veut pas dire que le taux d'endettement de la duplication est simple :

Dans certains contextes, la duplication peut être introduite pour réduire le couplage, ce qui signifie qu'elle peut réduire d'autres dettes et, par conséquent, elle agit comme un crédit. Le code mort peut être reconnu comme une dette résultant de l'obsolescence mais qu'en est-il de la duplication dans le code mort ? Dans de tels cas, le dédoublement est détaxé.

Bien sûr, nous pouvons toujours fabriquer des valeurs et des conversions, mais nous devons les reconnaître comme étant de la fiction plutôt que de la science, a conclu Henney. C'est un peu comme le calcul du Blue Monday, le troisième lundi de janvier, qui serait soi-disant le jour le plus déprimant de l'année selon une "formule pseudo-scientifique ce qui est une pure absurdité".

Pour conclure, ci-dessous les différents points sur lesquels Henney est revu pendant ses conférences sur les Six Impossible Things : 

  1. Il est impossible de représenter l'infini de manière aussi directe ; ou d'entretenir une précision infinie au sujet d'un ordinateur physique distinct car le stockage et les représentations sont délimités.
  2. Toutes les questions n'ont pas de réponse ; les développeurs doivent prendre conscience des modes de défaillance imprévue, avertir si une défaillance est possible et utiliser les pauses pour corriger et non pas attendre une réponse qui n'arrivera jamais. 
  3. La vérité ne peut pas toujours être établie ; car on ne peut pas vérifier toutes les conditions au préalables dans le code à cause des contraintes définitionnelles du langage de programmation.
  4. Le futur ne peut pas être défini à l'avance; pour faire face à des inconnues la solution consiste à être plus expérimental et à se concentrer sur des hypothèses dans notre façon de développer. 
  5. Un système distribué n'est pas défini à l'avance ; l'échec est normal et les systèmes distribués ne peuvent vérifier que deux des trois partitions à savoir la cohérence, la disponibilité et la tolérance.

Au sujet de l’Auteur

Evaluer cet article

Pertinence
Style

Contenu Éducatif

BT