Taxonomie de la dette technique (2018)

Taxonomie de la dette technique

Introduction

• Bill "LtRandolph" Clark est engineering manager de l’équipe Champions de LoL et s’intéresse de près à la dette technique.
• La dette technique est définie comme du code ou des données qui imposent un coût aux développeurs futurs.
• Cet article présente différents types de dette technique rencontrés chez Riot ainsi que le modèle utilisé en interne.

Métriques

Pour évaluer la dette technique, trois axes principaux sont utilisés : l’impact, le coût de correction et la contagiosité.

Impact

• Impact de la dette technique sur les joueurs et les développeurs.
• Bugs, fonctionnalités manquantes, comportements inattendus, etc.

Coût de correction

• Temps et risque nécessaires pour corriger la dette technique.
• Une erreur simple peut être corrigée en quelques minutes, mais un problème profondément enraciné peut prendre des semaines ou des mois.

Contagiosité

• Dans quelle mesure la dette technique peut se propager.
• Influence sur les interactions avec d’autres systèmes, la duplication des données et l’implémentation de nouvelles fonctionnalités.

Types de dette

Dette locale

• Le problème n’apparaît qu’à l’intérieur du système et n’a pas d’impact à l’extérieur.
• Exemple : Cataclysm de Jarvan.

Métriques de Cataclysm

• Impact : 1 / 5
• Coût de correction : 2 / 5
• Contagiosité : 1 / 5

Dette MacGyver

• Cas où deux systèmes incompatibles sont reliés par une solution de fortune.
• Exemple : std::string en C++ et la classe AString de Riot.

Métriques std::string vs AString

• Impact : 2 / 5
• Coût de correction : 3 / 5
• Contagiosité : -2 / 5

Dette de fondation

• Cas où des hypothèses enfouies au plus profond du système affectent l’ensemble de celui-ci.
• Exemple : l’utilisation du langage de scripting lua dans LoL.

Métriques de BlockBuilder Lua

• Impact : 4 / 5
• Coût de correction : 4 / 5
• Contagiosité : 4 / 5

Dette de données

• Cas où beaucoup de contenu s’est empilé sur d’autres types de dette technique, rendant la correction difficile et risquée.
• Exemple : le bug des noms de paramètres dans le langage de scripting BlockBuilder.

Métriques du bug des noms de paramètres

• Impact : 2 / 5
• Coût de correction : 2 / 5
• Contagiosité : 4 / 5

Résumé

• Lorsqu’on évalue la dette technique, il faut prendre en compte l’impact, le coût de correction et la contagiosité.
• La contagiosité indique la probabilité que la dette technique se propage, et l’ignorer peut mener à de gros problèmes.
• La dette technique peut être classée en quatre catégories : dette locale, dette MacGyver, dette de fondation et dette de données.

Résumé de GN⁺

• Cet article aide les développeurs à prendre de meilleures décisions en expliquant les types de dette technique et la manière de les évaluer.
• Il insiste sur la contagiosité de la dette technique et souligne l’importance de résoudre les problèmes tôt.
• Parmi d’autres projets aux fonctionnalités similaires, on peut citer Dota 2 et Overwatch.

[GN⁺]

Avis Hacker News

• L’interface est l’un des éléments les plus importants d’une conception et doit être examinée avec soin

  • Une belle interface peut facilement être améliorée avec le temps, mais l’inverse est rare

• La dette du fondateur est une dette créée par les fondateurs pour fournir rapidement une bonne technologie

  • Les documents fondateurs de nombreux pays relèvent aussi de cette catégorie

• Il est surprenant que cet article ait été écrit par un engineering manager

  • Il n’y a pas de managers promus en interne, avec une tendance à recruter à l’extérieur

• Une taxonomie de la dette technique est discutée

  • Lien connexe : A Taxonomy of Technical Debt
  • Lien connexe : A Taxonomy of Tech Debt (2018)

• Excellent article d’un point de vue technique

  • « nomenclature » serait peut-être une expression plus appropriée
  • Chaque exemple pousse vraiment à la réflexion

• « Contagion » est utilisé pour expliquer la dette technique

  • C’est une excellente explication

• La dette technique est définie comme du code ou des données dont les futurs développeurs devront payer le coût

  • Lorsqu’on crée de la dette, il faut équilibrer le besoin immédiat et le coût futur
  • Il y a une aversion presque pathologique envers la dette

• Je n’appellerais pas la « dette locale » de la dette technique dans un contexte général

  • Il y aura toujours du désordre quelque part, et il est courant de l’encapsuler

• J’ai travaillé dans plusieurs startups

  • Les fondateurs confondent souvent l’idée, ce qui a réellement été implémenté et ce qui fonctionne effectivement

• Il arrive qu’on assume volontairement de la dette technique pour un gain à court terme

  • Ce gain devrait aussi être pris en compte sur un autre axe