J’ai participé récemment à certaines discussions sur l’utilité de la métrique LOC (Lines Of Code). Comme expliqué dans certains posts précédents, c’est la première métrique que je regarde lorsque j’effectue un audit de la qualité d’une application. Et j’utilise cette métrique uniquement dans le but de me faire une idée de la taille de l’application.

Ensuite, j’examinerai d’autres métrique, comme la Complexité Cyclomatique (CC) afin de me faire une idée de son poids fonctionnel. Il est toujours intéressant de recouper ces mesures, par exemple en calculant le nombre de LOC et la CC moyenne par méthode ou par classe. Ceci permet de repérer des classes ou des méthodes qui sont difficilement compréhensibles, soit parce que le développeur devra parcourir sur son écran un fichier important de haut en bas afin de suivre le flux d’instructions, soit parce qu’un nombre important de conditions et/ou de boucles rendra ce flux et la logique applicative plus complexe à comprendre. De telle sorte que le risque est plus élevé de créer un défaut lorsqu’une modification est effectuée dans le code.

Si vous parlez de LOC dans une discussion, vous rencontrerez probablement quelques personnes qui vous diront que cette métrique ne devrait pas être utilisée pour mesurer la productivité ou l’effort. Je suis d’accord pour dire que c’est incorrect, l’utilisation de cette métrique doit se limiter à mesurer la taille.

Les points de fonction (PF) sont souvent considérés comme la meilleure métrique pour mesurer la productivité. Ils présentent certainement des avantages, notamment de pouvoir être utilisé avec des spécifications fonctionnelles, avant même de commencer le développement, de sorte que les PF permettent d’évaluer l’effort nécessaire pour mettre en œuvre ces spécifications dans le code et d’estimer la charge nécessaire en jours/homme. Toutefois, cette métrique présente, à mon avis, un inconvénient majeur : il n’est pas facile d’automatiser son calcul avec un outil d’analyse de code et un expert en Points de Fonction sera très prudent, pour ne pas dire suspicieux, dès lors qu’il devra utiliser des points de fonction calculés automatiquement.

En travaillant sur les posts précédents avec le plugin City Model pour Sonar, j’ai découvert que eXcentia, la société espagnole à l’origine de ce plugin, en a également créé un pour calculer une métrique ABC.

Je vous laisse découvrir la description de cette métrique, à partir d’un document de son auteur Jerry Fitzpatrick, ici.

Cette métrique est basée sur :

• A: Assignation d’une valeur à une variable.
• B: Branche, appel d’une function ou d’un nouvel objet.
• C: Condition, un test.

J’ai téléchargé le plugin ABC depuis cette page sur le site d’eXcentia, et l’ai installé dans mon environnement Sonar.

Ensuite, j’ai créé une classe ‘TestAssignment.java’ composé de 50 assignations comme celles-ci:

int var1=0;

int var2=0;

…

J’ai lancé une analyse Sonar depuis Jenkins (si vous souhaitez tenter par vous-mêmes, vous pouvez vous référer à certains posts antérieurs tels que celui-ci).

Voici le résultat : un unique édifice pour une classe unique. Et voici les valeurs obtenues :

• ABC = 50, correspondant aux 50 assignations que nous avons créées.
• LOC = 55, correspondant aux 50 assignations et quelques lignes supplémentaires afin de déclarer la classe et son unique méthode.
• Complexity = 1, le minimum possible puisqu’il n’y a aucune complexité.

Ensuite, j’ai créé une nouvelle classe ‘TestCondition.java’ avec le code suivant:

public class TestCondition {

int var1=0;

public TestCondition() {

if (this.var1 = 0){

this.var1 = 1;

}

else{

this.var1 = 2;

}

…

et le test dans ce code dupliqué 8 fois, afin d’obtenir aproximativement le même nombre de lignes de code que la classe précédente TestAssignment. A noter que nous aurons également 25 assignations: 3 dans chaque test x 8 duplications du test = 24 + 1 correspondant à la déclaration initiale de la variable var1.

J’obtiens maintenant deux édifices, de la même taille puisque ces deux classes ont (presque) le même nombre de LOC mais l’une est en rouge puisque son niveau de CC par méthode est élevé.

Cependant, la métrique ABC pour cette nouvelle classe n’est que très légèrement supérieure aux 25 assignations dans son code, ce qui montre que la complexité ne pèse pas beaucoup dans le résultat.

Comme vous pouvez l’imaginer, j’ai ensuite créé une troisième classe ‘TestBranch.java’ avec 50 instructions ‘new’ :

TestCondition myCondition1 = new TestCondition();

TestCondition myCondition2 = new TestCondition();

…

TestCondition myCondition50 = new TestCondition();

La hauteur reste la même, mais maitenant la valeur ABC est la plus importante puisque nous avons 50 assignations qui accompagnent les 50 traitements de type ‘Branch’.

Cependant, la métrique ABC n’a pas doublé para rapport à la classe TestAssignement. Cette dernière comporte 50 assignations pour une valeur ABC de 50, alors que la classe TestBranch a 50 assignations ET 50 ‘branches’, mais une valeur ABC légèrement au-dessus de 70.

Donc, que pouvons nous dire au sujet de cette métrique ABC?

Tout d’abord, nous pouvons voir différentes valeurs pour ces trois classes comportant un même nombre de LOC. Donc la métrique ABC est bien indépendante du nombre de lignes de code.

Cela dit, je ne suis pas certain qu’on puisse l’utiliser comme une mesure de la productivité ou de l’effort de maintenance puisque que nous pouvons constater que le A de Assignment pèse beaucoup dans son calcul. Le C de Condition est clairement sous-évalué. Or il est évident que l’effort nécessaire pour effectuer une modification dans une structure de 8 ‘if-else’ est plus élevé que pour introduire une modification dans une séquence de 50 assignations. D’autant que les conditions seront le plus souvent imbriquées (un if dans un if dans un autre if, etc.)

Et la plupart du temps, un branchement occasionnera de nouvelles assignations. Et nous pouvons voir également que ajouter 50 branches à 50 assignations ne double pas le résultat par rapport à 50 assignations sans aucun branchement. Ceci est dû à la formule de calcul de la métrique ABC. Alors qu’en fait, je pense que l’effort du programmeur sera multiplié par bien plus de deux.

Aussi, quel usage pouvons nous faire de la métrique ABC ? A cause de la prédominance du A de Assignment et de la sous-évaluation du C de Condition et, dans une moindre mesure, du B de Branch, je pense que cette métrique est plus orientée ‘données’ que ‘logique’. Ce qui n’est pas un problème, puisque nous bénéficions déjà de la Complexité Cyclomatique pour évaluer la complexité fonctionnelle.

Donc j’ai créé une nouvelle modélisation d’une City avec:

• La hauteur toujours basée sur le nombre de LOC.
• La largeur basée sur le nombre d’assignations, le A de la métrique ABC.
• La couleur basée sur la valeur globale de la métrique, de 1 (vert) à 100 (rouge).

Voici ce que j’obtiens pour les trois classes de mon test :

Les trois édifices ont toujours la même hauteur.

Le plus petit en vert est la classe TestCondition avec une largeur de 25 correspondant à ses 25 assignations et une couleur correspondant à sa valeur ABC de 26.2, donc sous-évaluant le C de Condition.

Les deux autres blocks correspondent aux classes TestAssignment et TestBranch avec une même largeur de 50 correspondant au nombre d’assignations mais le building TestBranch est plus rouge que celui pour TestAssignment à cause des traitements de branchement.

Cette représentation visuelle permet de mieux comprendre comment utiliser la métrique ABC. Je ne l’utiliserais pas pour mesurer l’effort de maintenance mais plutôt l’orientation ou le poids des données dans un objet, en prenant en compte la largeur de chaque édifice, et une mesure globale du risque pour ce composant, basée sur sa couleur. Un composant sera risqué soit parce qu’il présente une certaine complexité ou plus probablement un couplage important en plus de son poids en structures de données.

Le plugin ABC de eXcentia vient avec son propre widget (nous avons vu dans notre post précédent comment l’ajouter dans notre dashboard Sonar afin de le personnaliser) :

Nous pouvons voir différents nombres pour la métrique ABC:

• Un total de 134.9 sur l’ensemble de l’application.
• Une moyenne de 45 par classe, ce qui représente un risque modéré au niveau d’une classe.
• Une moyenne de 45 par méthode, ce qui représente un risque plus élevé et un refactoring devrait être envisagé pour les 2 méthodes avec une valeur ABC supérieure à 45.

Donc ce widget est en ligne avec l’utilisation que nous recommandons pour la métrique ABC, basée sur le risque d’introduire un défaut lorsqu’une modification est effectuée sur un composant.

Et si je souhaite une meilleure appréciation de ce risque, le plugin ABC me permet d’effectuer un drill-down.

Ici, j’ai sélectionné l’édifice le plus à risque dans ma modélisation de City, correspondant à la classe TestBranch, avec ses différentes valeurs.

Il me suffit de cliquer sur son nom pour descendre jusqu’à un onglet spécifique à la métrique et aux mesures ABC pour cet objet.

Le mix des deux plugins eXcentia pour Sonar, City Model et ABC permet une évaluation visuelle du niveau de risque et du besoin de refactoring pour une application.

Voici un exemple réel: ici, j’ai analysé un package dont je sais qu’il contient quelques classes dangereuses:

Nous pouvons voir sur la droite le quartier ‘TestABC’ correspondant à ce package avec les trois classes que nous avons créées pour nos tests. Maintenant, dans cette représentation, j’ai modifié l’expression pour calculer la largeur de chaque édifice afin de prendre en compte le nombre moyen d’assignations par méthode, et non plus le nombre total pour la classe comme précédemment.

Dans la figure ci-dessus, je pointe la tour rouge très élevée, sur la gauche, une classe ‘SesionUsuario’ qui gère toutes les données de la session d’un utilisateur dans l’application. Nous pouvons constater:

• Un mombre de lignes de code de 2 700 LOC, ce qui explique la hauteur de la tour.
• Une valeur ABC globale de 538.6, ce qui explique la couleur rouge de la tour.
• Que cette valeur globale est basée sur 522 Assignments.
• Un nombre important de méthodes: 67, ce qui explique la largeur de la tour (522 Assignments / 67 méthodes).

Un drill-down sur cette classe montre la présence de 71 Branchs et 112 Conditions dans son code. Cela confirme la surévaluation des Assignments dans la valeur globale de la métrique ABC.

Avec les paramètres initiaux du plugin City Model, cette classe apparaîtrait aussi haute, avec une base plus importante basée sur le nombre de ses méthodes, mais complètement verte parce que sa Complexité Cyclomatiquue par méthode serait assez basse. Donc elle nous semblerait un composant important mais pas nécessairement en première position pour un refactoring.

En utilisant les mesures ABC, la largeur est beaucoup moins importante, puisque la valeur ABC par méthode est assez peu élevé, mais elle apparaît complètement rouge, ce qui attire immédiatement notre attention sur le risque d’introducire un défaut lors d’une modification sur cette classe. Donc maintenant ce composant constitue un bon candidat pour une opération de refactoring.

Il faut bien sûr prendre en compte d’autres facteurs tels que la qualité du code sur la base du non-respect des bonnes pratiques de programmation. Néanmoins, cet exemple nous permet de voir que :

• LOC est une mesure de la taille technique d’une application, qui ne convient pas pour évaluer le poids fonctionnel, la productivité d’une équipe de projet ou estimer un effort de maintenance.
• CC est une bonne mesure du poids fonctionnel basé sur le nombre de chemins logiques mais ce n’est pas forcément un bon indicateur en matière de priorités de refactoring.
• Je pense que la métrique ABC est une bonne mesure du ‘data weight’ ou poids des données d’un composant, sur la base de la surévaluation des ‘assignments’ et de sa formule, donc à ce titre un bon complèment de la CC, plus orientée ‘logique’.
• Nous avons pu modélisé une City sur la base des plugins de eXcentia pour Sonar, qui nous aide à identifier rapidement quels sont les ‘risky components’ et à pointer les candidats prioritaires pour un plan de refactoring.

Il est probable que l’on peut imaginer toutes sortes de représentations basées sur le City Model, afin d’adresser différentes questions. Encore d’autres opportunités d’expérimenter ce beau jouet dans le futur.

 

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.