Loi de Goodhart et effet cobra dans les systèmes d’information (S.I.) qui utilisent SonarQube pour résoudre des problèmes de craftsmanship.

Loi de Goodhart

« lorsqu’une mesure devient un objectif, elle cesse d’être une bonne mesure »

SonarQube

SonarQube est un logiciel libre de qualimétrie en continu de code. Il aide à la détection, la classification et la résolution de défauts dans le code source.

Effet cobra

L’effet cobra est un phénomène indésiré, qui se produit lorsqu’une tentative de résolution d’un problème a pour effet pervers une aggravation de ce même problème.

Le contexte

Je vais vous raconter une petite histoire factice, et pourtant si réaliste, de la société TrucMuche et de son S.I.

Le S.I. 2.0 de TrucMuche

Dans bien des S.I. la qualité du code est un sujet que l’on prend au sérieux, et c’est bien sûr le cas chez TrucMuche. On a envie de bien faire, et que ce soit au goût du jour, bien entendu. Le pipeline CI/CD est en place. Et pour la qualité du code on choisit SonarQube bien évidemment: avec ça on va « faire propre ». C’est sûr, c’est le descriptif du produit qui le dit. Les motivations de son adoption sont variées: des projets qui dérapent, une compréhension basique du craftsmanship/clean code, un besoin de reporting/surveillance.

Une étape « cruciale », le taux de couverture

Vient alors le temps du choix de l’indicateur de la couverture de code: à partir de quel pourcentage « c’est-y que c’est que le code qu’il est bien »? Tout le monde y va de son appréciation, les idées fusent :

• 40 %… on part de loin il faut y aller progressivement
• 60 %… il faut être plus ambitieux
• 100% … on fait de la qualité ou en fait pas
• 80 %… c’est un bon compromis, ça fait sérieux et on ne peut pas être parfait
  Ok, va pour 80 %!

En avant toutes!

Tout le monde est content, désormais tout nouveau code ne pourra pas avoir de couverture en deçà de 80 %, le but étant bien entendu de porter la couverture globale de tout le S.I. à ce niveau d’exigence.
A ce moment il faudrait se demander pourquoi on « découvre » si tard que le code a une mauvaise couverture, sans avoir relié ce fait à l’un des phénomènes suivants: chaque modification de code à un endroit fait régresser à un autre endroit, les temps de développement pour un même type de fonctionnalité se rallongent au fil du temps. Mais ça, personne ne se le demande.
Quoiqu’il en soit, la machine est lancée, les développeurs – les mêmes vraisemblablement qui ont contribué consciemment ou non, contraints ou non, aux problèmes suscités – vont maintenant produire du code propre: on a Sonar, on est entré de plain pied dans le troisième millénaire, les générations futures de développeurs louerons nos exploits.

Et vogue la galère!

Maintenant, la pression est mise un maximum sur les équipes, les indicateurs doivent passer au vert, les 80 %, on doit par là-même indiquer que l’on fait un code de qualité ! Les méthodes ne changent pas, les deadlines sont toujours présentes et puisqu’il faut faire du chiffre, on emploie les grands moyens:
TestBed, Mockito et consorts sont de la partie. Avec ces outils, pas besoin de découpler, de se soucier de SRP, de tests unitaires (les « vrais »), de clean code quoi: on pond le code en temps et en heure, et les tests d’intégration feront le job.

Le cercle vicieux – ou le cobra qui se mord la queue

Évidemment, en restant sur cette trajectoire les choses ne vont pas s’améliorer, on aura de la dorure en surface (80% de couverture – ou plus -) mais un code inmaintenable, incompréhensible.
D’ailleurs, on rentre dans une espèce de cercle vicieux :

• indicateur de « qualité de code » (point de départ)
• objectif de satisfaction des indicateurs
• méthodes discutables de développement
• code de mauvaise qualité
• difficile à maintenir
• difficile à tester
• besoin de compensation des défauts du code et de satisfaire les indicateurs
• utilisation de bibliothèques de tests qui dispensent de découpler, écriture d’assertions ridicules
• le code n’est pas meilleur
• les ennuis reviennent au galop (bugs, régressions, allongement du temps de développement « iso périmètre »)
• il faut relever les exigences de qualité
• on ajoute d’autres indicateurs ou on relève les exigences

retour au point de départ

La morale de cette histoire

Bien, j’espère que vous avez pu reconnaître la loi de Goodhart et l’effet cobra dans ce cas d’école au combien réaliste.
Je tiens à signaler que je n’ai rien contre SonarQube, ni TestBed, ni Mockito : ce sont de bons outils si l’ont s’en sert à bon escient.
Il faut se demander pourquoi on veut utiliser tel ou tel outil.
Je veux utiliser SonarQube pour avoir du bon code => Pourquoi ai-je du mauvais code sans SonarQube ?
Je veux utiliser Mockito parce que c’est plus simple pour tester => Pourquoi est-ce que mon code est difficile à tester ?
Et ainsi de suite…
Personnellement j’essaye de me servir de Mockito (ou équivalent) le plus tard possible dans le développement du code. A contrario, si très rapidement on est obligé d’employer la « grosse artillerie », c’est qu’il y a quelque chose qui ne tourne pas rond dans le code.
Je n’ai rien non plus contre les cobras ni Python.

Voilà, si cet article vous a plu : en voici d’autres. Cet article vous a déplu, vengez-vous lâchement dans les commentaires! 🙂