La dette technique ce n’est pas de la dette, et ce n’est pas technique.

Lorsque nous disons que le code d’une application présente de la dette technique, deux simplifications s’opèrent :

1) nous considérons le problème uniquement sous l’angle du code

2) nous convertissons ce problème en euros

On sait bien que le problème n’est pas intrinsèquement dans le code lui-même. On dit souvent que le code “pourrit”, mais en réalité, le code c’est-ce qu’il y a de plus stable dans notre industrie.

Ce code legacy en C, soigneusement rangé au fond d’un disque sur mon NAS, depuis la dernière amélioration que j’y ai apporté le mardi 19 janvier 1993, il n’a pas changé d’un bit : c’est tout le reste qui a changé.

C’est ce qui rend le code legacy si intéressant : il reflète des conversations qui se sont perdues depuis longtemps. C’est une traduction enfouie.

J’ai extrait ce code en vue d’en faire “chiffrer la dette technique” par trois personnes expérimentées.

Ce code implémente une table de hachage en C, ce qui permettait, à l’époque, de stocker en mémoire des dictionnaires de types “clé/valeur” assez performants.

A : Le C, c’est portable. Bravo, c’est du code propre que tu as là. Est-ce qu’il y a des tests au fait ?

B : Pourquoi t’embêter avec ce code quand n’importe quel langage moderne offre gratuitement des dictionnaires clé/valeur ? A minima, tu pourrais utiliser glib…

C : Qu’est-ce que tu veux faire précisément, avec ce code ?

Ni A,ni B, ni C ne me fournissant une réponse chiffrée, tournons-nous vers l’outil cité hier, qui propose cette métrique :

Technical Debt (sqale_index): Effort to fix all Code Smells. The measure is stored in minutes in the database. An 8-hour day is assumed when values are shown in days.

Il semble que ceux qui ont mis au point cet outil cherchaient un nom qui sonne bien plus que tout autre chose. De ces trois suppositions audacieuses :

1) la dette technique c’est un ensemble de “code smells”,

2) que l’on peut détecter automatiquement,

3) dont le coût de réparation en minutes est connu.

la numéro 3 est la plus spectaculaire. Elle amène tant de questions :

  • avec ou sans tests automatisés ?
  • avec ou sans relecture de code ?
  • à l’aide de quelle documentation ?
  • est-ce qu’il y a un délai de réparation ?
  • qui prend en charge la réparation ?
  • avec quelle expérience ou ancienneté dans le langage ?
  • avec quelle expérience du refactoring ?
  • avec quelle connaissance du contexte métier dans lequel tourne ce code ?
  • est-ce que la réparation se fera en binôme ou en solo ?
  • quelles compétences spécifiques sont requises ?
  • est-ce qu’on testera la réparation ?

On peut s’arrêter là, on voit bien que c’est sans espoir. En matière de chiffrage automatique, l’outil n’a pas toutes les réponses; il n’a même pas les bonnes questions.

Pour en savoir plus sur la dette technique, ne manquez pas mon prochain post sur le sujet, demain !

publié sur Linked In le 20/01/2023