Contrôler la qualité de ses projets avec Sonar

La page d'accueil d'un projet est son dashboard, qui se divise en plusieurs blocs d'informations, catégorisant ainsi les métriques (voir chapitre suivant traitant de ces métriques). Ces blocs sont appelés "widgets" et sont paramétrables par l'administrateur (possibilité d'ajouter, supprimer et déplacer ces widgets).

Sans être exhaustif, voici quelques-uns de ces blocs.

Le premier bloc montre les statistiques principales, comme le nombre de lignes de code, de packages, de classes Java, etc.

Le bloc suivant montre le pourcentage de commentaires présents dans le code, ainsi que la part de code dupliqué.

Le troisième bloc d'informations se focalise sur la répartition de la complexité cyclomatique par méthode ou par classe.

Les blocs suivants sont destinés à afficher les résultats de l'exécution des tests unitaires : couverture du code, pourcentage de réussite, etc.

Un autre bloc nous montre le taux de respect des règles de codage, ainsi que la répartition, en fonction de leur sévérité, des violations de ces règles présentes dans le projet.

Un autre widget est dédié à l'affichage des éventuelles alertes, comme nous pouvons le voir ci-dessous :

Enfin, il est possible que certains plugins additionnels proposent leur propre widget, qui pourra alors afficher les informations relatives à leur fonction. On peut voir ainsi les widgets des plugins Tags, Build Stability, JaCoCo ou encore Technical Debt:

La vue "Components" permet d'afficher la même vue que la page d'accueil de Sonar, mais où chaque élément affiché correspond à un module de l'application. Un module peut être soit un module au sens Maven (dans le cas de projet multimodules), soit la liste des packages Java. Cette vue permet ainsi d'obtenir une vision plus fine de la qualité.

La vue "Violations drilldown" montre l'ensemble des violations des règles de qualité présentes dans le projet.

Le premier bloc affiche le nombre total de violations sur le projet. Celles-ci sont ventilées soit selon leur sévérité (bloquante, critique, majeure, mineure ou information).

Le deuxième bloc affiche l'ensemble des règles non respectées sur le projet, ainsi que l'occurrence de ces violations.

Les autres blocs montrent, pour chaque module, package ou classe, le nombre total de violations.

En cliquant sur l'une de ces règles (affichée dans le deuxième bloc), on fait afficher, dans les blocs du bas, les modules, packages et classes Java violant cette règle-là. Par exemple, en cliquant sur la règle "Bad practice - equals() method does not check for null argument", on visualise où se situent ces violations :

V-B-4-a. Time machine▲

Depuis les toutes premières versions de Sonar, cet outil propose une fonctionnalité très intéressante, à savoir la "Time Machine". Elle permet de visualiser simplement l'évolution des différentes mesures au cours du temps sur un projet donné, et donc également de comparer l'état de l'application entre deux dates. L'accès à cette fonctionnalité se fait via le bouton "Time machine" présent dans le menu à gauche.

Au-dessous du graphique, de nombreux indicateurs sont présents. Il suffit de sélectionner ceux pour lesquels nous souhaitons voir l'évolution, puis de cliquer sur le bouton "Compare on chart". Le graphique se met alors à jour pour afficher les nouvelles métriques.

On voit que Sonar intègre sur le graphique certaines dates "importantes" (marquées par une ligne verticale) :

• le changement de version (dans le pom.xml) ;
• un seuil d'alerte a été franchi (appelé "Alert Red (was Orange)" par exemple) ;
• une alerte a été stoppée (appelée "Green (was Orange)" par exemple).

Chacun de ces événements affichés résulte en une colonne dans le tableau présenté sous le graphique. Grâce au bouton "Show date" situé dans l'entête de tableau, on peut ajouter une nouvelle date pour une comparaison affinée. De même, chaque colonne dispose d'un bouton "hide" pour la faire disparaitre du tableau.

V-B-4-b. Vue différentielle▲

Sur les versions récentes de Sonar a été intégrée la fonctionnalité de vue différentielle. Elle permet de connaître l'évolution des métriques sur un laps de temps donné. Par défaut, nous pouvons comparer l'état courant avec l'état :

• 5 jours auparavant ;
• 30 jours auparavant ;
• l'une des deux dates ou périodes fixées dans la configuration du projet (options Period 4 et Period 5).

Ces dates sont paramétrables.

Nous pouvons ainsi demander à Sonar d'afficher dans la vue "Dashboard" l'évolution des métriques sur une période d'un mois :

On peut noter que cette vue différentielle se retrouve à d'autres endroits, comme nous le voyons ci-dessous avec la vue d'une classe Java :

La vue "Clouds", ou "Nuages" est une double page mettant en lumière les classes ayant un intérêt particulier. Dans ces vues, le nom des classes Java est affiché plus ou moins grand, en fonction de l'importance de la classe. Il y a deux catégories de nuages :

• les "Quick wins" ;
• les "Top risk".

La page "Quick wins" montre ainsi les classes qui, pour un effort relativement faible, augmenteront significativement la qualité générale de l'application. Plus un nom de classe est écrit grand, plus la classe disposera d'une complexité cyclomatique forte. Quant à la couleur, elle correspond à la couverture du code, ou au respect des règles de codage. Ainsi, dans la capture suivante, la classe "CoreMetrics" est écrite en grand (elle a une forte complexité) mais elle est en bleu, car sa couverture est bonne.

La page "Top risk" reprend le même principe, mais se base sur d'autres critères. Ici, la taille du texte indique la complexité par méthode (et non plus la complexité générale de la classe) et la met en parallèle avec le respect des règles de codage ou la couverture de code. Ainsi, une classe écrite en grand et en rouge montre une classe ayant un risque d'erreur important.

Lorsque l'on clique sur le nom d'une classe (quel que soit le type de nuage), on est automatiquement redirigé vers le code source de la classe.

La vue "Design" montre sous forme de tableau, les dépendances entre les modules (ou les packages ou les classes, selon le niveau où l'on se trouve).

La vue "Hotspots" montre, au sein d'une même page, les points d'intérêt sur le projet.

Ces informations sont séparées en blocs distincts :

• "Most violated rules" liste les règles ayant le plus de violations.
• "Most violated" montre les classes Java ayant le plus de violations de règles.
• "Longest unit tests" indique quelles classes prennent le plus de temps pour exécuter les tests unitaires.
• "Highest untested lines" indique les classes ayant le plus de lignes non couvertes par les tests unitaires.
• "Highest complexity" montre les classes ayant la plus forte complexité cyclomatique.
• "Highest average method complexity" liste les classes ayant les plus fortes complexités moyennes par méthode.
• "Highest duplications" montre les classes ayant le plus de code dupliqué.
• "Most undocumented file APIs" met en lumière les classes ayant peu de documentation.
• "Highest (Lack of cohesion of methods | Response for class)" montrent les classes ayant un fort LCOM4 ou RFC.

Cette vue affiche pour chaque composant les dépendances avec des librairies tierces.

Cette vue n'est accessible qu'aux administrateurs. Elle permet de paramétrer le projet (voir le sous-chapitre "Gestion des projets" du chapitre "Administration" pour plus de détails).

Cette vue permet de définir les utilisateurs ou groupes (voir chapitre sur l'administration de Sonar) pour chaque rôle, qui sont :

• Administrateurs: peuvent tout faire sur ce projet ;
• Utilisateurs : peuvent naviguer dans le projet, mais n'ont pas accès au code source ou à la configuration ;
• Accès au code : peuvent voir le code source du projet.

Nous n'allons pas ici parler de toutes les métriques, cela serait fastidieux et pas forcément utile. Comme nous l'avons déjà vu, Sonar remonte pour chaque projet un nombre assez important de métriques, ces métriques étant de plus disponibles sur plusieurs niveaux (projet, module, package, classe, etc.).

Il peut être intéressant de connaître la façon dont telle ou telle mesure a été réalisée sur une métrique donnée. C'est dans cette optique qu'une page du wiki de Sonar a été écrite, regroupant les principales métriques, leur définition et leur méthode de calcul. On pourra ainsi découvrir la différence entre la couverture par ligne, par branche ou globale (voir chapitre suivant), ou encore la façon dont Sonar va calculer, pour un fichier donné, le nombre de lignes de code, d'instructions, de commentaires, etc.

Obtenir des métriques est une chose, savoir les interpréter en est une autre, bien plus compliquée qu'il n'y parait ! Prenons un exemple : la couverture de code. Il est évident que nous chercherons à obtenir le meilleur score sur cette métrique, mais signifie-t-elle pour autant que notre code est parfait ? Considérons le code Java suivant :

public String maMethode(boolean condition) {
    String str = null;
    if (condition) {
        str = "ma chaine";
    }
    return str.trim();
}

Nous pourrions écrire un test JUnit suivant pour tester notre méthode :

@Test
public void testMaMethode() {
    assertEquals("ma chaine", maClasse.maMethode(true));
}

Ce test JUnit nous permet d'obtenir 100 % de couverture de code, mais pourtant, mon code n'est pas exempt de bogue, puisqu'il retournera un NullPointerException si je donne la valeur false au paramètre condition. En réalité, la couverture de code n'est pas ici de 100 %, c'est la couverture de ligne qui est à 100 %. Autrement dit, chaque ligne du code a été exécutée par le test JUnit. Ici, la couverture par branche n'est pas de 100 %, car la méthode peut en réalité être lue comme ceci :

public String maMethode(boolean condition) {
    String str = null;
    if (condition) {
        str = "ma chaine";
    } else {
        // Ne rien faire.
    }
    return str.trim();
}

Or le bloc else n'a pas été exécuté par notre test JUnit. C'est d'ailleurs pour ceci que Sonar propose trois valeurs de couverture de test :

• couverture de lignes : pourcentage de lignes de code exécutées par les tests unitaires ;
• couverture de branches : pourcentage de branches effectivement parcourues par les tests unitaires ;
• couverture globale : sorte de pondération entre les deux précédentes valeurs.

Et même si nous atteignons une couverture totale de 100 %, cela ne signifie absolument pas que le code soit exempt de bogue ! Toutefois, cela nous permet d'avoir une plus grande confiance dans le livrable final.

Il est possible d'arriver de différentes façons jusqu'au niveau d'une classe du projet. À partir de là, il est possible de voir le code source selon plusieurs critères :

• "Coverage" pour voir la couverture du code de cette classe par les tests unitaires ;
• "Dependencies" pour connaitre les dépendances de cette classe ;
• "Duplications" qui affiche les lignes de code dont il a été trouvé des duplications ;
• "LCOM4" ("Lack of cohesion of methods") qui mesure le nombre de composants connectés à cette classe (voir ici pour plus d'informations) ;
• "Source" qui montre le code source brut ;
• "Violations" qui montre le code source en y indiquant les violations rencontrées.

Ainsi, en visualisant le code source d'une classe avec les violations, nous voyons apparaitre ce type d'écran :

Pour plus de lisibilité, des options permettent de n'afficher que certaines violations (via le "filter") et n'affichent pas le code propre (on peut voir l'intégralité du code source en cliquant sur la case "Expand").

Pour des raisons de sécurité, il est possible de demander à Sonar de ne pas importer le code source dans Sonar. Ainsi, cette visualisation ne sera plus possible si cette option est désactivée (elle est active par défaut). Pour faire cela, il suffit de se rendre (en tant qu'administrateur) dans la configuration de Sonar, puis dans "General", et enfin de changer la valeur de l'option "Import sources". Il est également possible de le faire en ajoutant à sa commande Maven l'option "-Dsonar.importSources=false".

Depuis la version 2.8 de Sonar, il est possible de réaliser des revues de code sur Sonar. Dans la vue "Violations", pour chaque violation, il est possible de réaliser les actions suivantes :

• marquer comme faux positif : cette violation n'est pas considérée comme une erreur dans ce cas précis, et Sonar doit désormais l'ignorer ;
• supprimer un faux positif : dans le cas où une violation a été considérée comme un faux positif, alors qu'il s'agissait bien d'une erreur ;
• faire une revue : laisser un commentaire sur cette violation, ce qui permettra par exemple de créer une demande de correction par un développeur ;
• réassigner (dans le cas d'une revue existante) : permet de réassigner à une autre personne une revue existante.

Au sein de la page d'accueil, on peut lister l'ensemble des revues et les filtrer en fonction de leur sévérité (ou plus exactement de la sévérité de la violation qui y est liée), du statut ou encore du projet :