Lorsqu’une entreprise a pris conscience de problèmes qu’elle rencontre liés à la qualité de ses logiciels, elle met en place une stratégie pour progresser sur différents axes : tests, déploiement, qualité du code,… Sur ce dernier point précisément, le plan d’action comprend bien souvent de la formation, du coaching technique, un changement de culture et de modèle d’organisation des équipes, le déploiement de solutions logicielles, … Après plusieurs mois de mise en œuvre concrète, quelles sont les pistes pour mesurer l’amélioration de la qualité du code ? Quels indicateurs mettre en œuvre ? Déjà, est-ce vraiment possible ? Voici des éléments de réponse.

Mais d’abord, c’est quoi la qualité d’un code source ? 

C’est LA question qui revient souvent. Quels sont les critères qui définissent la qualité du code ? Comment peut-on mesurer la qualité du code ? Benoit Ganteaume en parle régulièrement dans son excellent Podcast Artisan Développeur (notamment dans cet épisode).

Si l’on pourrait parler longuement des avis et prises de position sur ce sujet, essayons de garder en tête qu’un code du qualité est avant tout un code propre, clair et compréhensible par toute personne autre que son auteur, testé automatiquement (et donc testable par nature), et qui répond aux besoins spécifiés par le métier. C’est donc un code qu’il sera facile de faire évoluer. Nous garderons pour la suite de cet article que la qualité de code se mesure (dans un monde idéal) selon ces critères, même si d’autres comme la performance sont pertinents dans certains contextes.

Nous vous présentons maintenant 5 éléments de réponse pour identifier ces indicateurs d’amélioration du code.

#1 La Qualimétrie 

Une approche traditionnelle consiste à utiliser des outils d’analyse automatique de code permettant d’identifier certains problèmes et axes d’amélioration, qu’on appelle généralement des “code smells”. Des linters, tels qu’Eslint par exemple, en sont capables. La qualimétrie propose un ensemble de métriques dont le but est d’évaluer le niveau de maintenabilité, de fiabilité, d’extensibilité, ou encore de clarté du code. Par exemple :

• Taux de couverture de code
• Nombre de tests unitaires
• Complexité cyclomatique et cognitive des méthodes
• Taux de duplication de code
• Taille des classes et des méthodes

L’idée ensuite est de mesurer l’évolution de ces indicateurs dans le temps pour voir les résultats obtenus par l’équipe de développement. Diminution de la complexité du code, du nombre de défauts de code, amélioration de la couverture évoquent naturellement des signes d’amélioration.

Si ils offrent un premier niveau d’aperçu sur les tendances en termes de qualité, il faut néanmoins garder à l’esprit que ces indicateurs ne peuvent, à eux seuls, refléter une réelle amélioration de la qualité du code : est-ce que les opérations de découpage du code, qui ont permis de diminuer sa complexité, rendent ce code plus maintenable ? Les tests unitaires ajoutés, qui ont permis d’augmenter la couverture, apportent-ils une réelle valeur ?

ll faut être prudent pour que tous les efforts de l’équipe ne soient pas uniquement dirigés sur ces indicateurs. Les problèmes de fond (pourquoi peu de tests ? pourquoi un code complexe ?) doivent d’abord être traités, et la mise en place de nouvelles pratiques dans l’équipe doit être une priorité, au-delà des indicateurs en eux-mêmes.

#2 La Vélocité 

La vélocité met en lumière l’effort qu’une équipe peut investir sur une durée donnée (un Sprint généralement). Dans les méthodes Agiles, on mesure souvent cet effort en story points. Plus la vélocité est importante, plus l’équipe saura “accomplir” des tâches. Ainsi, on peut s’imaginer que si l’état du code s’est amélioré ces derniers mois, probablement que les évolutions ont été moins coûteuses à apporter dans le code, et qu’il est logique d’observer une hausse de la vélocité.

Néanmoins, la vélocité n’est pas seulement liée à la qualité d’un code. Le processus de gestion du backlog, les contraintes externes à l’équipe, l’impact des parties prenantes d’un projet sont autant de facteurs qui peuvent générer du retard et de la complexité pour l’équipe technique. Également, si la façon d’estimer l’effort (les story points) évolue à travers le temps, ou si les tâches sont découpées différemment, cette vélocité évoluera même si l’état du code reste inchangé.

Le temps de validation des tâches est un indicateur intéressant également, par exemple le temps consacré à la revue de code, le nombre d’allers-retours entre l’auteur et le relecteur, le nombre de retours formulés dans les revues… On imagine qu’un code propre et clair demandera moins de temps à relire.

#3 Le nombre de bugs

Quand on parle d’amélioration de la qualité, on pense naturellement à une diminution du nombre de bugs. Dans une approche “Quality by design”, l’identification des bugs est un processus intégré très tôt et en continu dans les phases de développement. Il est possible de mesurer sur plusieurs mois le nombre de bugs remontés sur l’application, en utilisant les outils de gestions de tickets (comme JIRA).

Cette valeur, bien qu’intéressante, nécessite de prendre en compte d’autres critères. Par exemple, si le nombre d’utilisateurs du logiciel a quadruplé ces derniers mois, il ne serait pas surprenant de constater une augmentation du nombre de bugs remontés. Il faut aussi analyser chaque bug pour étudier si il vient d’un problème au niveau du code. Parfois, un bug est dû à une simple erreur de configuration de l’infrastructure Cloud. Un travail préalable de catégorisation de chaque bug remonté sur plusieurs mois s’avère donc pertinent.

#4 Les “Four Key Metrics”

Le DORA (the DevOps Research and Assessment) a produit en 2019 le “State of Devops Report”, résumant 6 années de travaux de recherche sur la performance opérationnelle des entreprises IT. Une partie des résultats de leurs recherches est parue dans le livre “Accelerate” (Jez Humble, Nicole Forsgren PhD Gene Kim).

Il y est notamment présenté 4 indicateurs, les Four Key Metrics, qui mettent en avant la performance des équipes de développement :

• Deployment Frequency (DF) –  La fréquence à laquelle ont lieu les mises en production

• Lead Time for Changes (LTFC) – Le temps moyen pour qu’une modification de code arrive en production

• Change Failure Rate (CFR) – Le pourcentage de mises en production ayant engendré des bugs

• Mean-Time-To-Restore (MTTR) – Le temps nécessaire pour corriger un problème apparu en production (et effectuer une restauration de la précédente version si nécessaire)

Au premier abord, ces métriques paraissent plus proches d’une culture DevOps qu’une culture “qualité du code”. Cependant, il est intéressant d’observer que :

• Dans un projet où le code est bien structuré et autorise des évolutions à faible coût, il est probable que les déploiements pourront se faire plus fréquemment.

• Dans un projet où le code est automatiquement testé à différents niveaux (unitaires/intégration/fonctionnels/…), prévenant ainsi le risque de régressions, l’équipe sera plus sereine pour livrer fréquemment et diminuer le CFR.

Ces 4 indicateurs sont en fait intimement liés. En effet, si tout le processus d’intégration et déploiement continu (CI/CD) est entièrement automatisé, le DF et LTFC seront plutôt élevés. En revanche, en l’absence de stratégie de tests et d’amélioration continue du code, le CFR sera probablement impacté. Les bugfix et autres correctifs à chaud seront fréquents.

Ces 4 key metrics sont en fait un bon révélateur du niveau de maîtrise du code au sein d’une organisation. Sans elle, l’équipe n’aura pas une bonne vision de l’impact et des conséquences des changements faits sur le code : est-ce que le code fait la même chose qu’avant ? est-ce que l’on a pas cassé quelque chose ailleurs ? Gagner en maîtrise amplifie la confiance qu’a l’équipe à faire évoluer sa base de code et ainsi à la livrer avec une meilleure qualité du code. “On va retarder de 3 jours la livraison, on a encore plusieurs tests manuels à effectuer” : si cette phrase revient souvent, elle dénote peut-être d’un manque de confiance de l’équipe envers son code, mais aussi d’une stratégie de tests perfectible.

#5 Le ressenti des équipes et du métier

Sur la durée, la satisfaction du métier (le client) se mesure en partie à la capacité de l’équipe à s’adapter aux changements et à délivrer régulièrement de la valeur. Si les estimations des tâches à accomplir seront par nature erronées à l’arrivée, l’écart réel aura tendance à être amplifié si le code est complexe. Là où la tâche demandée paraît “simple” en théorie, en pratique le temps nécessaire varie suivant l’état du code ou la présence de tests de non-régression. Si ces écarts réels se répètent, ils risquent de générer de la frustration côté métier.

Du côté des développeurs, leur présence sur la durée dans une équipe révèle souvent son bon état de santé : bonne cohésion entre les personnes, défis proposés captivants, méthodes de travail enrichissantes, …. A l’inverse, un turnover fréquent est signe que l’environnement, code compris, est peut-être toxique pour les développeurs. Rester trop longtemps sur un projet, avec un code en mauvais état et aucun signe d’amélioration, peut avoir des conséquences néfastes.

In fine, la satisfaction des utilisateurs finaux est aussi un bon indicateur. Une application mobile notée 5 étoiles sur les stores, c’est une bonne chose, surtout lors du lancement. Par contre, si cette note demeure constante sur 12 ou 24 mois, c’est encore mieux ! Cela signifie qu’il y a régulièrement des nouveautés et de la valeur ajoutée donc, et quasiment pas de bugs ou de régressions (ce qui revient un peu au point #4, ne trouvez-vous pas ?)

Ce ressenti humain, très qualitatif, à la fois côté équipe de développement et côté métier, devrait selon nous toujours être pris en compte dans ce type de démarche d’amélioration continue.

Bonus : Un classique…

Proposé en 2008 par Thom Holwerda, cet indicateur assez subjectif présentera certaines complexités opérationnelles pour être efficacement mesuré ! 😉

A-t-on vraiment besoin d’indicateurs ? 

Connaissez-vous la “Loi de Goodhart” ? Elle stipule que lorsqu’une mesure devient un objectif, elle cesse d’être une bonne mesure. Dans un contexte où l’on recherche en permanence des indicateurs-clés de performance (des KPIs), il faut garder une certaine vigilance sur ces indicateurs, qui peuvent être facilement contournés ou “tordus” de manière contre-productive : le meilleur exemple reste l’ajout de tests unitaires sans valeur, avec pour seul objectif d’augmenter la couverture de code. 

De notre point de vue, le management par la métrique est un terrain glissant, qui traduit souvent un problème de confiance entre management et équipes IT. Il sera préférable d’étudier des alternatives et de travailler d’abord sur ce problème de fond, plutôt que d’avoir une stratégie qui vise uniquement à améliorer ces indicateurs.

Qu’en conclure ?

Dans cet article, nous avons proposé plusieurs approches complémentaires pour évaluer des améliorations sur la qualité du code dans le temps. Les dernières tendances soutiennent l’utilisation des “Four Key Metrics”, ce qui s’explique par la diffusion de plus en plus forte de la culture DevOps au sein des entreprises. En plus de l’aspect quantitatif des indicateurs, l’approche qualitative et le ressenti humain sont de bons compléments pour évaluer l’impact d’une démarche d’amélioration de la qualité du code.

La mention “Raising the bar” du manifeste du Software Craftsmanship est un concept central : la propension d’une équipe à élever en permanence son niveau doit faire partie de ses priorités. Les indicateurs cités dans cet article s’amélioreront naturellement si cette culture est bien en place. L’équipe doit donc être accompagnée pour rentrer dans cette dynamique. Des outils comme le pair programming, les Ateliers Craft, la revue de code, le TDD sont des pistes à exploiter pour y arriver. 

Et vous, avez-vous des indicateurs à proposer ? Ou besoin de conseils pour savoir comment mettre en place une stratégie d’amélioration continue afin d’optimiser la qualité du code ? Parlons-en !