Contrôler la qualité de ses projets avec Sonar


précédentsommairesuivant

V. Visualisation des données

V-A. Liste des projets

Lorsque l'on se connecte sur la page d'accueil de son serveur Sonar, on visualise l'ensemble des projets gérés par Sonar. Cette liste est un tableau où sont affichées les principales informations pour chaque projet, comme par exemple :

  • le nom du projet ;
  • sa version ;
  • la taille du projet ;
  • le taux de respect des règles ;
  • quand a été réalisé le dernier build ;
  • les principaux liens (vers l'application, le site du projet, le serveur d'intégration continue, le serveur de gestion des sources, etc.) ;
  • les éventuelles alertes sur le projet ;
  • etc.
Image non disponible

L'administrateur de Sonar peut toutefois éditer les informations affichées dans ce tableau afin de présenter d'autres informations sur cette page de garde (voir le chapitre sur l'administration).

Le second onglet de cette page, appelé "Treemap" offre une vue où chaque projet est symbolisé par un carré, dont la taille et la couleur indiquent le niveau de certaines métriques (par exemple le nombre de lignes de code, des informations sur les tests unitaires, etc.). En survolant le carré correspondant à un projet, une info-bulle donnera de plus amples informations.

Image non disponible

Pour obtenir les détails d'un projet en particulier, il suffit de cliquer sur son nom, dans la liste. La vue d'un projet s'affiche alors...

V-B. Vue d'un projet

La vue d'un projet est composée du dashboard (l'écran de contrôle), ainsi que d'un menu à sa gauche. Ce menu permet d'accéder aux principales informations :

  • le "Dashboard" qui propose en une page une visualisation complète de la qualité du projet ;
  • le "Component" qui permet de voir la vue de chaque module composant le projet ;
  • le "Violations drilldown" est la page principale regroupant l'ensemble des violations des règles de qualité ;
  • la "Time machine" montre l'évolution du projet au cours du temps ;
  • les "Clouds", ou nuages, montrent les "quick wins" ou les points critiques du projet ;
  • le "Design", donnant des informations sur l'aspect design du projet, telles que les dépendances entre les modules ;
  • les "Hotspots" regroupent en une page les classes les plus influentes sur la qualité ;
  • les "libraries" listant les dépendances tierces de chaque module ;
  • les "Settings" permettent de configurer le projet (option visible seulement pour l'administrateur) ;
  • les "Project Roles" pour définir les droits des différents groupes sur ce projet (option visible seulement pour l'administrateur).
Image non disponible

D'autres menus peuvent apparaître avec l'utilisation de plugins (plugins SQALE, Motion chart, Radiotor ou Timeline par exemple).

V-B-1. Vue "Dashboard"

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.

Image non disponible

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

Image non disponible

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

Image non disponible

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.

Image non disponible

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.

Image non disponible

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

Image non disponible

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:

Image non disponible
Image non disponible

V-B-2. Vue "Components"

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é.

V-B-3. Vue "Violations drilldown"

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

Image non disponible

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).

Image non disponible

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

Image non disponible

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

Image non disponible

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 :

Image non disponible

V-B-4. Vue "Time machine"

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.

Image non disponible

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.

Image non disponible

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.

Image non disponible

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

Image non disponible

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 :

Image non disponible

V-B-5. Vue "Clouds"

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.

Image non disponible

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.

V-B-6. Vue "Design"

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).

Image non disponible

V-B-7. Vue "Hotspots"

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

Image non disponible

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.

V-B-8. Vue "Libraries"

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

Image non disponible

V-B-9. Vue "Settings"

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).

Image non disponible

V-B-10. Vue "Project Roles"

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.
Image non disponible

V-C. Les métriques

V-C-1. Les différentes métriques et leur mode de calcul

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.

V-C-2. Interprétation des résultats

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 :

 
Sélectionnez

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 :

 
Sélectionnez

@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 :

 
Sélectionnez

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.
Image non disponible

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.

V-D. Visualisation du code source

V-D-1. Vues

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 :

Image non disponible

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".

V-D-2. Revue de code

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.
Image non disponible

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 :

Image non disponible

précédentsommairesuivant

Vous avez aimé ce tutoriel ? Alors partagez-le en cliquant sur les boutons suivants : Viadeo Twitter Facebook Share on Google+   

Ce document est issu de http://www.developpez.com et reste la propriété exclusive de son auteur. La copie, modification et/ou distribution par quelque moyen que ce soit est soumise à l'obtention préalable de l'autorisation de l'auteur.