Un consultant Qualité me demande s’il est « possible de créer ses propres métriques avec Sonar ? » et « quel est le degré de facilité d’introduire de nouvelles régles ? ».

Je sais qu’il est en train de travailler avec un client qui souhaite se doter d’un outil d’analyse de code. Et c’est le critère typique que l’on retrouve traditionnellement dans tous les cahiers des charges lorsqu’il s’agit de choisir un tel outil.

C’est devenu une règle universellement admise, au point même que certains vendeurs de software en ont fait un argument de vente et intègrent dans leurs démos avant-vente la création d’une nouvelle règle. Ce n’est pas critique mais cela plaìt. Vous imaginez un vendeur de voitures ouvrir le capot d’un véhicule en marche pour régler le carbu ? Ce serait spectaculaire mais quel intérêt ?

J’ai déjà dit à quel point ce critère est dangereux dans ce post 8 critères de choix dun outil d’analyse de code. Mais je n’avais pas vraiment développé les raisons pour lesquelles je pense qu’inclure un tel critère dans un choix d’outil peut s’avérer une erreur.

La question de ce consultant (et ami) constitue une opportunité pour présenter quelques arguments en faveur de cette thèse mais surtout :

• Aider ceux qui souhaitent effectuer un choix d’outil à mieux comprendre comment utiliser ce critère.
• Aider les consultants Qualité à poser les questions utiles pour une meilleure définition et appréciation de ce critère dans un cahier des charges, en fonction du client, de son contexte, de ses technologies, de ses objectifs, etc.

Bref, quitte à utiliser ce critère, essayons de le faire intelligemment et en toute connaissance de cause.

Je vais d’abord présenter les diffèrents types de métriques ‘personnalisables’ et nous verrons ensuite quelle utilisation en faire, pour quelles technologies, et à quel coût.

Les différents types de métriques

Il existe toutes sortes de métriques, certaines simples, certaines plus complexes et certaines impossibles. Remarque préliminaire pour les puristes de la Qualité : pour des raisons de simplicité, je vais regrouper sous le même vocable de ‘métrique’ différentes notions de ‘régles’, ‘indicateurs’, ‘diagnostics’, etc. Merci donc de ne pas vous formaliser pour le vocabulaire employé. C’est mon blog, pas le dictionnaire de l’Académie française.

Métriques simples, de type indicateur

Imaginons que vous souhaitez mesurer le nombre de défauts critiques ou bloquants par rapport à la taille du code. Une application fait 50 000 lignes de code et comporte 500 violations critiques : la valeur de cette métrique, dans cette exemple, sera donc de 1 violation critique pour 100 lignes de code.

En l’espèce, on ne devrait pas parler de métrique mais d’indicateur, car ce résultat ne provient pas directement de l’analyse du code, mais du croisement de deux valeurs issues de l’analyse. En fait, vous n’avez pas besoin que l’outil puisse créer des métriques, simplement de pouvoir accéder aux résultats d’analyse, généralement par une requête dans la base de données oú sont stockés ces résultats, ou à l’aide d’un service Web avec Sonar.

Bonnes pratiques de programmation

Ces métriques mesurent (le plus souvent) l’utilisation de syntaxes qui enfreignent les bonnes pratiques de programmation. Dans tous les langages, certaines instructions sont prohibées parce qu’elles présentent un risque pour le bon fonctionnement de l’application, la performance de celle-ci, la maintenabilité ou la lisibilité du code, etc. L’objectif cette fois est donc d’identifier la syntaxe correspondante et d’en compter le nombre d’occurences.

C’est généralement la métrique que l’on associe au critère de ‘création de nouvelles régles’, et le cas utilisé le plus souvent dans une démo. Elle reste relativement simple dans la mesure oú il s’agit de rechercher une chaîne de texte correspondant à l’instruction prohibée : par exemple un ‘catch(Throwable)’ en Java, qui correspond à une gestion incorrecte des erreurs. Ou un ‘BREAK’ en ABAP qui aura pour effet d’interrompre brutalement le programme, ou son équivalent ‘STOP .. RUN’ en Cobol. Un programmeur peut utiliser ces instructions à fin de débugguer son code, et oublier de les supprimer ensuite, avec le risque de voir cette instruction s’exécuter en environnement de production. Je ne connais pas de ‘Blocker’ plus ‘bloquant’ que celui-ci.

La recherche d’une chaîne de texte n’est pas très compliquée, mais il faudra penser à tous les cas :

• ‘catch(Throwable xxx)’
• ‘catch (Throwable xxx)’ , avec un espace avant la parenthèse, voire plusieurs espaces ou une tabulation
• voire même : ‘catch
      (Throwable xxx)’ avec un saut de ligne avant la parenthèse.

Le développement d’une telle métrique nécessite l’utilisation d’expressions régulières – les fameuses RegExp – que nous n’allons pas détailler ici d’autant que je n’ai jamais été un expert de celles-ci (trop vieux pour les avoir apprises à  l’école).

Je souhaite simplement préciser que même une métrique simple basée sur une simple instruction ou chaîne de caractères va nécessiter un minimum de réflexion, pour ne pas dire de conception afin de bien identifier tous les cas possibles, la maîtrise des syntaxes RegExp, et des tests afin de vérifier que tous ces cas sont couverts.

La plupart sinon tous les outils d’analyse de code permettent la création de telles métriques. Avec plus ou moins de facilité certes, mais la facilité « à introduire une nouvelle régle » n’est pas en fait un critère si important puisque la difficulté réside dans le développement et le test des expressions régulières.

Je conseillerai simplement d’identifier les outils qui proposent de véritables usines à gaz pour créer de nouvelles règles :

• Utilisation de fichiers xml pour définir les règles personnalisées et gérer les expressions régulières, obligatoirement localisés dans un répertoire spécifique (généralement non indiqué dans la documentation) sinon le logiciel ne saura pas les prendre en compte,
• Gestion non automatisée des identifiants de règles : chaque règle doit avoir un ID (un numéro de règle) unique. Vous devez donc gérer vous-mêmes votre propre index de règles, et vous pouvez être sûrs que vous rencontrerez des conflits d’identifiants, surtout si vous êtes plusieurs à gérer ces règles et qu’une plage d’IDs spécifique n’est pas normalisée.
• Définition de traitements en base de données, pour compter le nombre de violations rencontrées pour les régles que vous avez définies.
• Gestion non automatisée de l’affichage de la métrique : certains outils regroupent les métriques par catégories, par poids, ou selon différents facteurs, et vous devez préciser oú vous souhaitez voir apparaître la métrique, dans quelle catégorie ou quel groupe de métriques.

A suivre dans le prochain post : nous parlerons de métriques complexes ou impossibles.

A bientôt.

 

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.