Publié par

Il y a 11 années -

Temps de lecture 9 minutes

Contrôles de qualité avec Sonar

La qualité d’une application étant directement liée à la qualité de son code, de nombreux outils sont apparus pour effectuer différents contrôles : reporting de tests unitaires, analyse de la couverture du code par les tests, vérifications du respect des règles de codage, de nommage des variables et méthodes, etc.

Sonar est un outil qui permet d’évaluer rapidement et clairement la qualité des projets Maven2, mais aussi d’autres types de projets, moyennant une « Mavenisation » assez simple. Il s’appuie sur des outils comme Checkstyle, PMD et Cobertura et offre un reporting web très intuitif pour synthétiser les résultats de ces différents outils et guider l’utilisateur sur la voie de la qualité.

Présentation

Sonar est un serveur de contrôle de qualité logiciel, développé par la société Hortis. Le but principal de Sonar est de proposer une synthèse des résultats de différents outils de contrôle de qualité existant. À cela viennent s’ajouter plusieurs méthodes de calcul permettant d’évaluer la qualité globale du projet. Pour cela, Sonar utilise les outils suivants :

  • JavaNCSS, pour les métriques de code source.
  • Checkstyle, pour les mesures de règle de codage.
  • PMD, pour détecter des problèmes comme du code dupliqué, des méthodes trop complexes, etc.
  • Surefire, pour lancer les tests unitaires
  • Cobertura, pour calculer la couverture des tests unitaires

Il est également possible d’utiliser Clover, l’outil d’analyse de couverture de chez Atlassian. Cependant, comme il nécessite une licence, Sonar demande un petit peu de configuration pour l’utiliser. Je vous renvoie aux documents listés dans la section Commencer à utiliser Sonar pour des précisions.

Fonctionnement

Le tableau de bord

Le site de démonstration de Sonar effectue en permanence du monitoring sur une trentaine de projets open-source. Pour décrire le fonctionnement du tableau de bord de suivi de projet, nous allons nous pencher sur le projet Apache Maven. Voici donc l’écran Sonar correspondant au projet. On peut y voir une foule de statistiques sur lesquelles nous reviendrons en détail dans les prochains paragraphes. La présentation est très claire, ce qui rend la lecture des résultats beaucoup plus directe.

Métriques

La partie haute du tableau de bord fait apparaître différentes métriques qui permettent d’appréhender la globalité du projet. Parmi ces données on retrouve :

  • Nombre de packages/classes/méthodes du projet
  • Quantité de code dupliqué, à minimiser pour augmenter la maintenabilité de l’ensemble
  • Pourcentage de code documenté avec le nombre de lignes de commentaires
  • Résultats et couvertures des tests

Sur la droite de cette section apparaît également un résumé des calculs de complexité cyclomatique sur l’ensemble des classes du projet. Il est à noter que plus le projet est complexe, plus le code sera difficile à relire et plus le projet deviendra difficile à maintenir au fil du temps.

Conformité aux règles de codage

Ensuite vient une section résumant le respect des règles de codage (optionnelles ou obligatoires). Le pourcentage final obtenu peut être déroutant de prime abord, aussi je vous donne l’algorithme :

Rules compliance = 100 - (100 - Efficiency) - (100 - Maintainability) - (100 - Portability) - (100 - Reliability) - (100 - Usability)

Chaque pourcentage de ce résumé est cliquable et nous amène vers un écran donnant le détail des violations de règles pour le thème choisi. Le détail laisse apparaître :

  • le pourcentage de satisfaction des règles pour chaque paquetage
  • le nombre violations pour chaque classe
  • le code source des classes avec les violations surlignées

Synthèse graphique par module/package/classe

On aborde ici un des aspects les plus intéressants de Sonar. Le graphique présenté ci-dessous permet de voir de façon très directe quels éléments du projet sont les plus critiques. Si votre projet est multi-modules, ils apparaissent ici, dans le cas contraire, nous arrivons directement au niveau paquetage. Les tailles différentes sont affectées en fonction du poids en code source.

Chaque rectangle est cliquable et permet de faire zoomer le tableau de bord jusqu’au sous-ensemble sélectionné. On peut ainsi obtenir le calcul de toutes les statistiques sur chaque paquetage de code et zoomer jusqu’au niveau classe.

La coloration de chaque rectangle donne un aperçu rapide de la qualité des paquetages du projet. Les boutons radio accolés permettent d’afficher la coloration :

  • du respect des règles de codage
  • de la couverture des tests

Profils de qualité

Les évaluations de Sonar sont basées sur un système de profils de qualité. Ces profils définissent des ensembles de règles de codage servant de base aux évaluations faites par l’outil.

Deux profils sont livrés par défaut : Sun checks et Sonar way, qui contiennent les bonnes pratiques telles que définies par le père de Java et l’équipe Sonar. Ces deux profils sont immuables, mais il est possible de créer un nouveau profil par copie de l’un des deux. Ces profils utilisateurs sont modifiables à loisir. On peut activer, désactiver ou rendre optionnelle une règle. Certaines règles sont également paramétrables : on peut par exemple définir une expression régulière pour fixer une norme de nommage.

Un point fait cependant débat dans la communauté des utilisateurs Sonar : il n’est pas possible de changer la méthode de calcul des pourcentages de « Coding rules compliance ». Étant données les demandes utilisateurs, cela sera peut-être possible dans le futur mais rien n’est moins sûr.

Alimentation en données

Sonar s’appuie sur une base de données pour afficher ses résultats. Les moteurs actuellement supportés sont MySQL 5.x, Oracle 10g XE et SQL Server 2005. L’alimentation en données est faite par le biais d’un plugin Maven 2. Pour les projets existants qui n’utilisent pas Maven, il est possible de rédigé un pom.xml minimal du type :






  4.0.0
  [YOUR.ORGANIZATION]
  [YOUR.PROJECT]
  [YOUR PROJECT NAME]
  [YOUR PROJECT VERSION]
  
        [YOUR SOURCE DIRECTORY]
        
           
              org.apache.maven.plugins
              maven-compiler-plugin
              
                  1.5
                  1.5
              
           
        
  
  
  	true
  

Extrait de la documentation officielle

Une fois muni de ce fichier pom.xml et moyennant une installation Maven 2 standard on peut alimenter Sonar avec les données de notre projet. Cela se fait très simplement en lançant la commande :

mvn org.codehaus.sonar:sonar-maven-plugin:1.4.1:sonar

Intégration continue

Une autre façon d’alimenter Sonar en données consiste à l’ajouter dans une chaîne d’intégration continue. Ainsi, on pourra créer dans le serveur d’intégration continue de notre choix un build contenant la commande ci-dessus, conditionné à la réussite du build classique du projet.

Il existe également un plugin pour le serveur d’intégration Hudson qui offre une meilleure intégration entre les deux outils. Pour plus de détails, voir la page d’accueil du projet.

Commencer à utiliser Sonar

Les ressources existantes sont plus que complètes, aussi il me semble superflu d’insérer dans cet article des informations techniques. Les documentations officielles sont efficaces et permettent de démarrer l’utilisation de Sonar en quelques minutes :

Je vous encourage à tester le tutoriel de démarrage rapide qui permet de se faire rapidement une idée de la qualité de son projet confronté aux standards Hortis et Sun. Cela réserve parfois des surprises.

Voici également un excellent guide en français, rédigé par Romain Linsolas sur Developpez.com :

L’actualité du projet

La prochaine version de Sonar sera la 1.5 et la liste des fonctionnalités attendues est, disons, conséquente :

  • Publication de points d’extension permettant à la communauté de facilement créer :
    • De nouvelles métriques
    • De nouveaux « handlers » Maven (exemple : pilotage des plugins Emma, jDepends, et autres)
    • De nouveaux services de calcul de métrique de second niveau (exemple : nombre de tests unitaires par rapport à la complexité cyclomatique globale)
    • De nouveaux services web de restitution de l’information en GWT (exemple : nuages de classes ou de projets)
  • Affichage de la couverture de code au sein du module de visualisation du code source. Pour l’instant, seules les violations aux règles qualité apparaissent
  • Exécution de Sonar sur des versions passées d’une application pour reconstituer un historique significatif (pour jouer Sonar sur les versions labellisées d’une application)
  • Intégration de Findbugs aux côtés de PMD et Checkstyle (ce qui fera passer Sonar à plus de 600 règles)
  • Possibilité de définir et d’alimenter manuellement de nouvelles métriques (exemples : nombre de développeurs, valeur métier de l’application, etc)
  • Amélioration technique : suppression de la double exécution des tests unitaires

Les API ne seront pas figées et Hortis annonce se laisser la possibilité de les faire légèrement évoluer sur le début 2009 en fonction des retours des utilisateurs.

Dernière minute : Hortis est sur le point d’annoncer la création d’une spin-off qui devrait être baptisée SonarSource. Cette entité sera dédiée à l’édition logicielle afin de péréniser le développement de l’outil Open Source Sonar.

Conclusions

Sonar est, à mon sens, un excellent outil de suivi, d’une simplicité déconcertante. Pour peu que vous utilisiez déjà des plugins Maven tels que Cobertura ou PMD, le tableau de bord Sonar donne une excellente vue synthétique. Les tâches de revue de code s’en trouvent particulièrement facilitées puisqu’il suffit d’adapter les règles de codage aux standards de l’équipe pour avoir une remontée d’informations rapide.

L’installation est aussi simple que la navigation est claire, la prise en main est rapide, un vrai plaisir. Sonar apporte un vrai plus comparé à la target mvn site dans sa présentation très synthétique. Là où le site généré par Maven oblige à naviguer dans les différents rapports de chaque outil, Sonar propose un regroupement des informations très pertinent.

L’ajout de Sonar à une chaîne d’intégration continue provoque souvent chez les développeurs l’envie de mieux faire pour faire grimper les scores. Somme toute, Sonar nous fourni une saine façon de responsabiliser les développeurs vis-à-vis de leur code et d’augmenter la qualité générale des projets.

Merci à Freddy Mallet pour ses précieuses informations sur le projet.

Publié par

Publié par Aurélien Maury

Aurélien est passionné par les frameworks web haute productivité comme Grails, JRuby on Rails ou Play! framework. Il est également intéressé par tous les aspects de performance et d'optimisation (mais aussi par la phytothérapie, la PNL, la basse électrique, la philosophie et pleins d'autres sujets). Il est également formateur au sein de Xebia Training .

Commentaire

3 réponses pour " Contrôles de qualité avec Sonar "

  1. Publié par , Il y a 10 années

    J’arrive certes bien après la parution de l’article, toutefois j’aimerai soulever un aspect passé sous silence : l’intégration dans l’IDE.

    Pour autant que j’ai pu voir, il n’y a en effet pas d’intégration réelle avec eclipse. Quelques plugins peuvent bien partager leur configuration avec Sonar (checkstyle par exemple), mais rien de plus. Il s’agit donc de « coup par coup ». De plus, m2eclipse semble poser des problèmes…

    Aussi, il ne reste que Maven à la ligne de commande est la seule option. Cela n’est pas forcément la plus productive des approches. Quand à avoir sonar tournant « en sous marin » via hudson, cela ferait que les retours sur les erreurs des développeurs soient asynchrones. Pas l’idéal pour la productivité…

    Encore fois, si l’avenir venait à montrer le contraire, je serai ravi !

    cordialement,
    joseph

  2. Publié par , Il y a 10 années

    Oui Sonar donne un joli tableau de bord quantitatif et qualitatif du code, qu’on peut même ‘driller’.
    Mais faut pas se leurrer non plus, Sonar est beaucoup trop limité et très brouillon en ce qui concerne la configuration des outils de génération de rapport : PMD, Cobertura ou FindBug.
    Alors qu’avec le pom.xml, la customisation de ces plugins est un jeu d’enfant, complet et est parfaitement clair, sur Sonar c’est le chaos et importer des règles relève du domaine du chaos.
    Avoir un tableau de bord joli avec un peu n’importe quoi comme indicateur, ca fait peut être bien pour les chefs à plume ou pour les vendeurs d’agilité, mais d’un point de vue de productivité, ça reste du vent.

  3. Publié par , Il y a 6 années

    Bonjour,

    il y’a combien de règles de codage pour le langage Java?

    J’ai chercher sur le site de sonar, mais je n’ai rien toruver …

    Cordialement

Laisser un commentaire

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

Nous recrutons

Être un Xebian, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.