« You can’t control what you can’t measure » (Tom de Marco)

J’expliquais dans le post précédent Les 3 coûts que les outils d’analyse de code nous fournissaient un grand nombre d’informations qualitatives alors que les métriques quantitatives étaient moins nombreuses, mais très utiles. Cette opinion n’est pas toujours partagée.

Les métriques quantitatives ou ‘raw metrics’ en anglais (que l’on pourrait traduire par ‘données brutes’) sont des mesures assez faciles á obtenir avec la grande majorité des outils d’analyse de code. Généralement, un tel outil commence par présenter une note globale de qualité qui agrège différentes règles en matière de bonnes pratiques de programmation, de design, de documentation, etc.
Cette simple note donne un aperçu général de la qualité de l’application, mais se révèle en fait assez subjective : elle dépend très fortement de l’outil.
Les bonnes pratiques qui régissent la qualité du code sont assez bien standardisées et on devrait donc retrouver les mêmes ensembles de règles au sein de chaque outil. Or, c’est peu souvent le cas. Certains logiciels sont spécialisés sur un langage unique pour lequel ils proposent le maximum de règles possibles. D’autres sont multi-technologies et visent á équilibrer voir á normaliser les règles entre les différents langages, et non pas á en supporter le plus possible.

Un facteur plus subjectif encore est la criticité accordée á une règle, son poids dans le modèle qualimétrique proposé. En réalisant une étude comparative entre deux outils, j’ai découvert que, sur une échelle de poids de 1 á 10 :

• Le premier outil proposait 15 diagnostics avec un poids de 6 á 10, sur un total de 73 règles, soit 20% de celles-ci.
• Le second outil proposait 58 diagnostics sur 102, avec un poids supérieur á 6, soit plus de la moitié du nombre total de régles.

Parfois, baisser ou relever simplement la criticité d’une règle suffit pour modifier drastiquement la note globale de qualité. Plus grave encore, il arrive qu’un outil se trompe dans la mesure d’une règle, soit parce qu’il produit un grand nombre de false-positives, soit tout simplement á cause d’un bug.

Je me souviens d’un logiciel d’analyse de code qui ne trouvait pas tous les liens vers la page d’erreur de l’application et en concluait qu’il y avait lá un grave défaut pour la sécurité de celle-ci. Emoi dans la salle lorsque l’équipe de projet et ses managers – et souvent un CIO – découvrent que leur application super-critique présente un risque majeur pour la sécurité. Grand moment de solitude pour le consultant Qualité qui présente cette conclusion sans avoir vérifié au préalable l’exactitude de cette mesure qualitative.

On en arrive donc á ce paradoxe que la qualité de votre application dépend… de la qualité du logiciel qui évalue la qualité de votre application.

Si deux outils distincts ne parviennent pas á la même mesure quand aux données qualitatives, les mesures quantitatives sont elles le plus souvent semblables et exactes.

J’entends souvent dire : « cette application est complexe » mais si je demande pourquoi elle est complexe, les réponses ne sont pas précises. Il me suffit de regarder le nombre de lignes de code et j’aurai déjà une indication. La taille de cette application est-elle plutôt en dessous ou plutôt au-dessus de la moyenne pour cette technologie ? Ensuite, la Complexité Cyclomatique me fournit une seconde information : cette application incorpore-t-elle un grand nombre de règles ? Son niveau de complexité la rend-elle facilement maintenable ?

Si vous savez qu’une personne pèse 60 kg, cela vous suffit-il pour dire si elle est mince ou pas ? Bien sûr que non. Mais si vous connaissez sa taille, alors vous pouvez dire si elle est ou non en surpoids.
Certaines mesures complémentaires telles que le taux de commentaires ou le pourcentage de code dupliqué permettent de reconstituer le profil de l’application. Bien sûr, les données quantitatives sont limitées. Certains me diront que c’est une hérésie d’utiliser le nombre de lignes de code, d’autres ne jurent que par les points de fonction. Tous ces avis présentent de l’intérêt, mais les ‘raw metrics’ présentent certains avantages indéniables :

• Elles sont facilement disponibles.
• Elles sont généralement exactes.
• Elles sont facilement compréhensibles pour le management de projet.

Elles constituent donc une base solide pour évaluer la qualité d’une application et si celle-ci est coûteuse á maintenir. L’examen des métriques qualitatives permet ensuite de préciser notre évaluation et le ‘pourquoi’ de ce coût : parce qu’elle est peu lisible, parce qu’elle présente des défauts pour sa fiabilité, parce que les bonnes pratiques en matière de performance ou d’optimisation ne sont pas appliquées, etc.

Les métriques qualitatives permettent d’affiner un diagnostic, de construire un plan de remédiation, de mettre en œuvre un processus d’amélioration continue de la qualité. Elles sont précieuses pour les équipes de projet.
Lorsqu’il s’agit de répondre á la question légitime des manageurs et des utilisateurs : combien me coûte cette application ? les données quantitatives sont plus simples, plus précises et plus faciles d’utilisation.

Commencons par mesurer ce que nous pouvons contrôler.

Cette publication est également disponible en Leer este articulo en castellano : liste des langues séparées par une virgule, Read that post in english : dernière langue.