J’ai continué à jouer avec le plugin City Model pour Sonar de eXcentia.

Pour ceux qui ont manqué les épisodes précédents, vous pouvez les trouver ici : City Model, City Model – Nouvelle version, La métrique ABC.

Ce plugin est vraiment très fun. Et tout le monde trouve fantastique une représentation visuelle de son code sous forme d’une cité. Aller à l’essentiel est important lorsque vous devez régulièrement juger de la qualité d’une application.

J’ai donc pensé à quelques cas simples mais fréquents, oú son utilisation va s’avérer précieuse. Ce qui me donnera également l’opportunité de démontrer à quel point il est simple à paramétrer.

Cité critique

Un client me demande un audit de deux de ses applications. Je creuse un peu pour savoir un peu plus précisément le ‘pourquoi’ de cet audit. Il peut y avoir plusieurs raisons, et j’ai besoin d’en savoir un peu plus afin de répondre précisément à sa demande.

Par exemple : il souhaite externaliser ces deux applications assez anciennes, et avant d’effectuer un appel d’offres auprès de différents outsourcers, il aimerait savoir quel est leur niveau de qualité. C’est effectivement une bonne idée, qui va lui permettre de mieux juger les offres qu’on lui présentera et de préciser un coût de maintenance. A l’heure actuelle, nombre de providers sont prêts à n’importe quoi pour obtenir un contrat. Estimer la dette technique sur ces applications lui permettra d’écarter les offres ‘low-cost’, peu réalistes.

Autre cas : le responsable d’un centre de développement se voit demander de reprendre une application. Assez compliquée à première vue: plusieurs centaines de milliers de lignes de code .NET, frameworks propriétaires, aucune documentation, etc. De quoi être un peu suspicieux. Il aimerait bien se donner un peu de visibilité sur la qualité de cette application et l’effort à effectuer pour cette reprise de code, avant d’accepter. Ou que je lui fournisse quelques arguments bien sentis pour justifier un éventuel refus.

En fait, le client dont je vous parle avait justement fait appel à un de ces outsourcers ‘low-cost’ pour développer ses applications. Retards, budgets en dépassement, beaucoup de bugs et d’utilisateurs mécontents, quelques situations de crise, l’image de l’IT dégradée, … bref, il cherchait quelques raisons d’expliquer à son provider qu’il ne voulait plus de lui.

Dés lors, je savais comment aller au plus important. Violations critiques. Lui montrer quelques bons gros bugs.

J’ai paramétré une analyse de code Sonar depuis Jenkins. Très simple : Sonar – Jenkins plugin. L’analyse fut très rapide.

Puis j’ai lancé mon dashboard Sonar préféré, comme Admin :

Je suis entré dans la configuration des widgets et j’ai ajouté un widget City Model Top de eXcentia.

Et j’ai entré les paramètres suivants :

• title : Blocker
• topListLength : 5. Je ne veux voir que les 5 premières violations de type ‘bloquantes’.
• formula : {blocker_violations}.

La formule correspond au top 5 des composants avec le plus de violations de type ‘Blocker’. Celles qu’on ne veut voir dans aucune application. Celles qui présentent le plus de risques pour les utilisateurs. Celles qui démontrent que l’outsourcer produit du code de la pire qualité qui soit.

Puis je vais ajouter le widget City Model et modifier ses paramètres.
Le premier champ ‘heightExp’ contient une formule pour définir la hauteur de chaque édifice en fonction de la taille de chaque classe, exprimée en nombre de lignes de code (Lines Of Code ou LOC).

Cette mesure utilise une fonction logarithmique afin d’éviter une croissance trop rapide et donc une différence de taille qui ferait que certains ‘gratte-ciels’ sortent du champ visuel et que les autres bâtiments apparaissent minuscules.

Je vais reprendre cette formule et la modifier afin d’utiliser une autre métrique : le nombre de ‘violations’ de bonnes pratiques, c’est-à-dire le nombre de défauts rencontrés dans le code :

Math.pow(Math.E – 0.25, Math.log({violations}))

Les autres paramètres sont les suivants :

• title : Blocker
• colorExp : num2col({blocker_violations}, 0, 1).
• widthExp : {functions}.

Je veux que les édifices représentant chaque classe apparaissent en rouge dés lors qu’existe au moins une violation critique, de type ‘Blocker’. Donc la formule ‘colorExp’ n’admet qu’un intervalle très étroit de valeurs: vert pour 0 ‘blocker’ et rouge dès lors qu’existe au moins un défaut bloquant, mesurée par la métrique {blocker_violations}.

La largeur de chaque building sera calculé en fonction du nombre de méthodes avec la métrique {functions}.

Une fois sauvés ces paramètres, voici à quoi ressemble ma ‘Cité critique’ :

N’oubliez pas que vous pouvez zoomer au sein de cette représentation ou la faire pivoter horizontalement ou verticalement, ce qui va nous permettre d’identifier les classes avec un ou plusieurs ‘Blockers’.

Cette grande tour verte à droite possède un grand nombre de défauts mais aucun critique. D’autres classes, même avec un nombre plus important de méthodes, présentent un au moins une violation bloquante.

Ces défauts doivent être corrigés impérativement avant même que l’application ne soit testée ou, a fortiori, soit installée en environnement de production.

En navigant au sein de cette représentation 3D, on peut rencontrer des classes qui autrement seraient indétectables de par leurs petites dimensions, en nombre de lignes de code ou de méthodes ou de complexité, mais qui compte néanmoins un bug bloquant.

Nous pouvons voir dans le coin inférieur gauche trois petites classes avec seulement deux méthodes et au moins 1 défaut bloquant.

Maintenant, nous voulons également identifier les classes avec un nombre élevé de défauts critiques ou majeurs. Voici les règles que j’ai définies en accord avec le client :

1. Une classe apparaît en rouge si elle comporte au moins une violation ‘Blocker’.
2. Une classe apparaît en rouge si elle comporte au moins quatre violations ‘Critical’. Sinon, sa couleur ira de verte à rouge en fonction d’une échelle de 1 à 4 de ces violations.
3. Sinon, la couleur de la classe sera définie selon le nombre de défauts ‘Major’ sur une échelle de 1 à 100.

Si je ramène ces trois règles sur une échelle de 1 à 100 :

• Une violation bloquante = 100.
• 4 violations critiques = 100, 3 violations critiques = 75, 2 violations critiques = 50 et 1 violation critique = 25.
• Les violations majeures sont mesurées sans facteur multiplicatif.

Et dernière règle, la couleur de l’édifice sera définie en fonction de la plus haute de ces valeurs. Par exemple :

• Une classe avec 30 violations majeures sans violation bloquante ou critique aura une couleur (de verte à rouge) égale à 30 sur une échelle de 1 à 100.
• Une classe avec 2 violations critiques sans violation bloquante ou majeure aura une couleur égale à 50, soit 2 violations x 25.
• Une classe avec 2 violations critiques et 30 violations majeures aura une valeur de 50 (plus haute des deux valeurs).
• Une classe avec 2 violations critiques et 60 violations majeures aura une valeur de 60.

Et voici la formule qui correspond à ces règles :

num2col(Math.max(({blocker_violations}*100), ({critical_violations}*25), {major_violations}), 0, 100)

Le résultat :

J’ai personnalisé mon dashboard avec 3 listes City Model Top correspondant à ces trois types de défaut :

Certaines classes avec des ‘Blockers’ comportent également un nombre élevé de défauts majeurs.

Conclusion

En guise de conclusion, si vous êtes un outsourcer, je pense que vous pourriez tirer profit de ces plugins. Par exemple, vous devez répondre à un appel d’offres :

• Organisez un rendez-vous avec votre client potentiel et demandez lui de préparer quelques extraits de l’application que celui-ci souhaite outsourcer, si possible comportant le plus de défauts.
• Analysez les en direct pendant la réunion et montrez lui les résultats. Vous pouvez jouer avec les paramètres en fonction des ‘top 10’ de chaque catégorie ou selon que vous souhaitez une cité plus ou moins ‘rouge’.
• Vous pouvez estimer avec le client une charge de correction de ces défauts ou de refactoring de ces classes.
• Vous pouvez demander au client dans quelle mesure ces extraits sont représentatifs de son code et donc évaluer l’effort global de reprise de l’application.

Votre client sera très certainement favorablement impressionné. De plus, les mesures obtenues constituent une base d’informations objectives qui permettent d’éviter le typique affrontement ‘client-fournisseur’ au profit d’un dialogue beaucoup plus constructif et réaliste. Votre client s’en souviendra au moment de choisir le prestataire auquel il confiera ses applications.

Autre exemple, utilisez ces plugins dans le cadre d’une Quality Gate :

• Analysez régulièrement votre code avec ces plugins.
• Corrigez immédiatement toute classe apparaissant en rouge.
• Effectuez une ultime analyse avant de livrer une nouvelle version de l’application ou d’un de ses modules et montrez le dashboard Sonar avec la cité correspondante.
• Vous pouvez vous permettre quelques défauts majeurs si l’urgence l’autorise, dès lors que vous vous engagez à les corriger par la suite.

Dans tous les cas, je vous recommande d’utiliser ces plugins pour Sonar avant que votre client ne les découvre. Ou que quelqu’un les lui fasse découvrir.

 

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.