Création de métriques personnalisées (4)

Métriques personnalisées Dernier article de notre série sur la création de métriques personnalisées.

Nous allons aborder dans celui-ci les différents coûts attachés à la customisation de métriques, et qui sont généralement mal identifiés voire complètement ignorés lors d’un projet d’acquisition d’un outil d’analyse de code.

Nous terminerons par résumer l’ensemble des différentes questions à se poser – ou à poser à un client – afin de déterminer si la création de métriques personnalisées constitue réellement un critère de choix pour un tel outil.  

Les coûts cachés

Coût d’implémentation

Un client va généralement vous poser la question « Est-ce facile de créer de nouvelles métriques avec tel outil ? » ou « Quel est le degré de difficulté ? », mais jamais « Combien cela me coûte de gérer mes propres métriques ? ». Or, il existe différents coûts de différentes natures.

Tout d’abord, il existe un coût à la création de métriques. Evidemment, les vendeurs de software ne vont pas vous le dire, mais au contraire vont s’attacher à vous cacher ceux-ci, avec une belle démo de création d’une règle en direct. Or il s’agira le plus souvent d’une métrique simple et non pas d’une règle complexe. Et nous avons vu dans le troisième article de cette série, consacrée à la personnalisation de métriques par technologie, que ce sont justement ces règles complexes qui sont les plus utiles et les plus fréquentes.

Donc contrairement à ce qu’on veut souvent faire croire, la création d’une métrique personnalisée ne se réalise pas sur un coin de table, mais nécessite un minimum de réflexion, pour ne pas dire de conception :

  • Souhaitez-vous identifier dans le code l’utilisation d’une instruction révélatrice d’une violation à une bonne pratique de programmation ?
    • Et dans ce cas, s’agit-il d’une instruction simple identifiable par une unique chaîne de caractères ou plutôt d’une instruction composée type ‘IF … THEN … ELSE … ENDIF’.
  • Devez-vous au contraire implémenter une règle d’architecture (type framework), comme nous l’avons vu dans le 3ème post de cette série.

Même pour un métrique simple basée sur une unique instruction, il vous faut penser à toutes les expressions possibles de celle-ci. Par exemple, un catch () peut s’écrire avec un espace ou non avant la parenthèse, et parfois cet espace sera en fait une tabulation, et vous pouvez même l’écrire sur plus d’une ligne si cela vous chante.

Même pour une métrique simple, il faut un minimum de réflexion afin de construire l’expression régulière, la fameuse RegExp qui va permettre d’implémenter celle-ci, et cela signifie procéder par tâtonnement et essai multiple. Croyez-moi, il n’y a que dans les démos que cela marche du premier coup !

Donc vous imaginez bien que pour une instruction composée, cela devient beaucoup plus compliquée. Et vous avez un grand nombre de règles qui combinent plusieurs instructions, comme par exemple les règles de structuration avec des instructions imbriquées (un IF dans un IF dans un IF, etc.), ou les violations au bonnes pratiques de performance pour des instructions gourmandes en mémoire (création d’objets, appel de méthodes par exemple) rencontrées au sein d’une boucle.

Et nous n’avons parlé jusqu’ici que de l’identification du code spécifique à une métrique, à travers une RegExp. Si vous devez parcourir un arbre syntaxique, ce sera plus compliqué. Si vous devez programmer une règle d’architecture, ce sera plus compliqué. Dans la plupart des cas, c’est toujours plus compliqué.

Le développement ne s’arrête pas à seulement à identifier des instructions dans des fichiers, il sera parfois nécessaire de programmer le calcul des résultats, par exemple, en développant des procédures stockées. Ou tout autre calcul nécessaire à l’affichage de la métrique dans le tableau de bord, comme par exemple, le pourcentage de violations rencontrées pour l’ensemble des instructions correspondantes.

Enfin, il faut également se poser la question de l’affichage de la métrique. Tous les outils vont forcément catégoriser une métrique sur un axe de gravité – de mineure à critique ou bloquante. Certains vous obligeront également à spécifier d’autres paramètres afin que la métrique apparaisse dans un tableau de bord, par exemple la place de cette règle dans un modèle qualimétrique, selon qu’elle impacte la maintenabilité, ou la performance, ou la robustesse, etc.

Ce que je veux souligner, c’est que la création de métriques personnalisées doit être abordée comme un véritable projet, avec :

  • Une phase de conception : quelles sont les métriques que vous souhaitez implémenter ? Sont-elles définies dans un cahier de règles ? Quels sont les différents cas possibles, les différentes syntaxes possibles, les RegExp correspondantes, etc.
  • Une phase de développement : l’écriture des RegExp ou la programmation de la recherche dans l’arbre syntaxique, et un minimum de tests unitaires.
  • Une phase de QA, avec de véritables jeux de tests, couvrant l’ensemble des différents cas possibles identifiés, combinant plusieurs occurrences d’une même règle au sein d’un même programme, la vérification des résultats – le comptage des violations, l’identification de false-positives – et de leur affichage dans le tableau de bord.

Coût de maintenance

Le coût de développement de règles personnalisées peut donc atteindre rapidement plusieurs dizaines de jours-hommes. Mais il existe encore d’autres coûts ultérieurs.

Le premier, le plus fréquent et auquel on pense peu : que se passe-t-il lorsque vous installez une nouvelle version du logiciel d’analyse de code ? Vous avez effectué un développement, celui-ci est forcément implémenté quelque part, dans un fichier, un répertoire, un repository, un workspace, une base de données, etc.

Par exemple : la RegExp est définie dans un fichier xml dans tel répertoire, ainsi que dans une table de la la base de données avec une procédure stockée pour calculer certains résultats à afficher. Et bien que se passe-t-il en cas d’upgrade du logiciel ? La nouvelle version va-t-elle écraser les fichiers xml présents dans le répertoire ? Vous faut-il mettre à jour un fichier xml installé par défaut par le logiciel et précisant l’emplacement de ces fichiers xml ?

Faut-il importer et appliquer à nouveau la procédure stockée ? Faut-il importer votre propre modèle qualimétrique avec la définition de vos propres règles dans celui-ci afin de les voir s’afficher dans la nouvelle version du dashboard ?

Autre type de coût de maintenance : le logiciel a évolué, et votre développement ne fonctionne plus. Et oui, le mode de création des métriques peut, et va certainement évoluer dans le temps au fil des versions. Vous devrez alors modifier votre ‘package’ de métriques personnalisées afin de les adapter à la nouvelle version. Coût de maintenance évolutive.

Notez que vous pouvez également connaître des bugs. Par exemple, vous devez définir un numéro ou identifiant pour chacune de vos métriques, et manque de chance, il se trouve que la nouvelle version du logiciel implémente de nouvelles métriques qui utilisent ces mêmes identifiants. Vos règles n’apparaissent plus dans la nouvelle version du tableau de bord et vous devez rechercher pourquoi, puis ensuite faire évoluer vos propres développement afin de solutionner ce conflit d’IDs. Coût de maintenance corrective.

Cela signifie que vous allez devoir gérer vos développements en configuration. J’ai vu des clients, très mécontents, qui signalaient des régressions sur une nouvelle version, parce que certaines de leurs métriques avaient disparu après l’installation de la dernière release, alors qu’ils avaient tout simplement installé une version ancienne de leurs règles dans laquelle ces métriques n’existaient pas. Et çà. cela prend du temps à investiguer et à déceler l’origine de la soi-disante « régression ».

Enfin, pour éviter cela, il est préférable de tester de manière exhaustive et approfondie la nouvelle version avec vos propres règles. Ce qui signifie quelque documentation de quelques procédures de tests (en plus de la documentation de procédure d’upgrade du logiciel, de gestion des versions de votre ‘package’ de règles, etc.).

Donc en fait, j’ai inclus dans une même catégorie de coûts de maintenance toutes sortes de coûts d’upgrade, de corrections et d’évolutions, de tests, de documentation, etc. Mais il est important de bien les identifier dés le départ car vous pouvez constater qu’ils ne sont pas minces.

Les questions

Vous l’avez bien compris : la création de métriques personnalisées ne se justifie qu’en cas de besoin réel et important. Et donc le degré de facilité pour créer celles-ci ne doit pas être un critère de choix d’outil d’analyse de code. Au mieux, c’est un plus.

Si vous souhaitez acheter un vélo, vous pouvez vous offrir un vélo tout terrain de compétition, avec cadre en titane, fourche en carbone, 15 vitesses et roues tubeless. Mais si vous comptez l’utiliser pour aller faire des courses, ce ne sera pas le plus pratique, et le prix dépassera largement les bénéfices que vous en tirez. Sauf si votre intention est de vous faire plaisir évidemment.

C’est malheureusement souvent le cas, et cela devient dès lors difficile de faire renoncer quelqu’un décidé à s’offrir un cadeau. C’est notre travail de consultant de vérifier l’existence réelle d’un besoin et de mesurer les coûts cachés. Donc, les questions à poser :

  • Disposez vous de règles de Qualité et bonnes pratiques que vous souhaitez automatiser ? En cas de réponse négative, je ne vois pas réellement de cas qui justifie la possibilité de créer ses  propres métriques.

Souvent, la réponse sera ‘Non mais …’ suivie d’une tentative de justification à base d’arguments pas très précis. Il faut bien défendre son petit caprice, n’est-ce pas. Dans ce cas, je rappelle que 90% des utilisateurs d’un outil d’analyse de code se contentent des règles existantes, et que 90% des 10% qui développent leurs propres métriques abandonnent au bout de deux ans.

  • Quel type de métriques ?

J’ai connu un client qui voulait absolument les métriques de Halstead. Ces métriques comptent le nombre d’opérandes et / ou d’opérateurs, comme mesure de la complexité. Certains veulent parfois les indexs de maintenabilité du SEI (combinaison de métriques telles que le nombre de lignes de code, la complexité cyclomatique, le taux de commentaires, …).

Ces métriques sont tombées en désuétude, raison pour laquelle la plupart des outils d’analyse de code ne les proposent plus. Pourquoi investir dans la création de telles métriques alors que celles existantes sont bien plus pertinentes ? Pourquoi alourdir l’utilisation d’un outil et la lecture d’un tableau de bord avec des mesures imprécises ?

Il y a aussi ceux qui ne sont pas satisfaits avec les catégories ‘Critical’ ou ‘Blockers’ de métriques existantes, et veulent une créer une catégorie spécifique rien que pour eux, quelque chose comme des ‘super-extra-blockers’. J’appelle cela le syndrome Spinal Tap : This one goes to eleven.

  • Si oui, pour quelles technologies ?

Comme vu dans dans le post précédent, c’est dans le domaine des applications SAP que vous rencontrerez assez souvent un besoin réel. Dans le monde des nouvelles technologies : J2EE, .NET, etc.  il existe déjà suffisamment de règles pour ne pas avoir à en créer de nouvelles, sauf le cas particulier des frameworks propriétaires.

  • Quel part du portfolio applicatif cette technologie représente-t-elle ?

Vous aurez toujours des clients qui voudront des métriques pour des langages peu courants ou très anciens : PL1, Pacbase, Informix, Fortran, etc. Ils disposeront même souvent d’un cahier de règles utilisées en interne pour des contrôles manuels. Il s’agit donc là d’un vrai besoin, mais les applications développées dans ces langages représentent rarement plus de 10% du parc applicatif, sont anciennes et généralement éprouvées, évoluent assez peu, etc.

  • Avez-vous un cahier de règles ou tout autre documentation sur vos règles ?

Si ce n’est pas le cas, je doute que ces règles soient effectivement appliquées.

Si vous avez un réel besoin de métriques personnalisées, si vous devez choisir un outil d’analyse de code sur ce critère de création et de gestion de métriques  personnalisées, iI est très important d’identifier précisément :

  • Quelles sont les différents étapes de création d’une métrique.
  • Ce que l’outil d’analyse de code fait automatiquement.
  • Ce qu’il ne fait pas : ce sera à vous de le faire.
  • Quelles sont les différentes actions à mener en cas d’upgrade de version.

Sur les 3 ou 4 logiciels que vous aurez retenu en short-list, préparez un test sous forme de pilote avec au programme quelques cas tel que:

  • Développement d’une métrique simple de type indicateur. Par exemple, pouvoir entrer un coût de projet en nombre de jours ou un nombre de personnes dans l’équipe de projet et diviser celui-ci par le nombre de défauts bloquants, critiques ou majeurs.
  • Développement d’une métrique simple de bonne pratique de programmation. Par exemple, identifier toutes les instructions write() et writeln() – imaginons qu’elles soient interdites au profit d’un système maison de gestion des messages. Prévoyez quelques fichiers de test avec des cas bien tordus d’instructions avec des espaces ou des sauts de lignes.
  • Développement d’une métrique complexe : identifier les instructions précédentes write() et writeln() dans une boucle. Là encore, imaginez quelques tests bien complexes, avec des boucles dans des boucles sur plusieurs pages par exemple.
  • Upgrade de version : demandez à chaque éditeur logiciel de packager les fichiers (ou tout autre objet) résultant du développement des 3 règles précédentes, avec une procédure d’installation ou d’upgrade. Faites un test d’upgrade de version (ou ré-installez la version actuelle) avec la procédure d’installation du package, afin de mesure la complexité de cette opération.

La création de métriques personnalisées n’est pas un critère de choix d’outil d’analyse de code si vous n’avez pas un réel besoin. Si c’est le cas, traitez ce critère avec le maximum de sérieux et identifiez bien les coûts cachés. Ne vous contentez pas d’une simple démo, faites un pilote, mettez à contribution l’éditeur logiciel. Eventuellement, faites vous assister.

Si vous souhaitez acheter un vélo de course, vous allez l’essayer non ? Vous n’allez pas vous contenter de demander au vendeur quel degré de faciliter pour pédaler ou changer la roue.

Ce article est également disponible en Leer este articulo en castellano et Read that post in english.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *