Sonar, l'outil qui manquait à l'usine de développement .NET

Sonar (www.sonarsource.org) est un outil de reporting sur la qualité des projets informatique. Bien qu'à l'origine fait pour le Java, la communauté Open Source a permis l'intégration de Sonar avec d'autre langages : cobol, flex, php, c++ et maintenant .NET.

L'objet de cet article est de vous montrer ce que peut apporter Sonar pour un projet informatique et montrer quelle est sa place dans l'univers .NET.

Sonar : des indicateurs de qualité du code

Sonar centralise les rapports d'outils d'analyse de code pour afficher des informations comme la couverture de test, le respect des normes de développements, la complexité, la duplication...

Il est important de prendre ces indicateurs pour ce qu'ils sont : des indices permettant de déceler de la dette technique. Il serait dangereux d'utiliser ces métriques dans l'absolu pour contractualiser la qualité attendue d'un projet.

Nous allons voir d'un peu plus près les métriques les plus significatives.

Tests unitaires et couverture

La seule façon de prouver qu'un code fonctionne, c'est de le tester.

Sonar permet de connaitre le nombre de tests unitaires joués, le taux de succès et la couverture de ces tests.

La couverture de tests correspond au pourcentage de lignes de code du projet qui est appelé pendant la phase de test. Attention : ce n'est pas parce qu'une ligne est appelée qu'elle est testée.

Une couverture élevée n'est donc pas une fin en soi. Par contre, une couverture basse est l'indice d'une carence dans les tests, ce qui est un risque pour le projet.

Une couverture élevée alors qu'il y a peu de tests implique que les tests ne sont pas unitaires, ce qui veut dire que le code couvert n'est probablement pas totalement testé.

Enfin, un taux de succès des tests qui n'est pas à 100% sous entend que les développeurs ne font pas attention lors du checkin/commit.

Complexité et cohérence

La complexité d'une méthode et la cohérence d'une classe sont des métriques qui permettent de mettre en évidence des problèmes de maintenabilité et de testabilité.

La complexité d'une méthode correspond plus ou moins au nombre de tests qu'il faudra faire pour couvrir tous les cas. Donc plus la méthode est complexe, plus elle sera difficile à maintenir et à tester.

La cohérence d'une classe (ici LCOM4) est un indicateur intéressant qui permet de trouver les classes qui pourraient facilement être découpées. La valeur LCOM4 correspond au nombre de classes qui pourraient résulter de ce découpage.

Règles de qualité du code

Il existe des outils d'analyse statique du code (exemples : Findbugs, Pmd en Java, FxCop, Gendarme en .NET) qui permettent de soulever des bugs potentiels ou des problèmes de maintenabilité.

Dans nos projets nous suivons la procédure suivante :

• Blocker : c'est un bug, on arrête tout et on corrige.
• Critical : il y a de fortes chances que ce soit un bug : on essaye de corriger rapidement.
• Major : ça ne sent pas bon, il vaudrait mieux regarder. On essaye de corriger avant la livraison.
• Minor et info : pensez à regarder si vous êtes curieux. En général, personne n'agit dessus, alors autant les désactiver.

La qualimétrie dans l'univers .NET

Dans l'univers .NET il existe des équivalents des outils permettant d'obtenir les métriques évoquées avant, mais il n'existe pas de solution de reporting  de celles-ci intégrée à l'usine de développement Team Foundation Server.

Team Foundation Server (TFS)

Le reporting TFS repose sur un cube OLAP contenant les données de build, de test et les work items. Il est donc possible de faire des extractions SQL à destination d'Excel, SharePoint ou Crystal Reports.

Néanmoins, ces rapports ne contiennent que des indicateurs de couverture de test, complexité cyclomatique ou de productivité (nombre de ligne produite, de bug résolu …). Les résultats des analyses de règles de qualité de code (FxCop, StyleCop, Gendarme, NDepend) ou de duplication de code (SourceMonitor) ne sont pas injectés dans le cube.

Ainsi, TFS ne permet pas de créer des rapports d'indicateurs qualimétriques provenant d'outils externes sans développement spécifique, d'où l'intérêt de Sonar.

Sonar pour les projet .NET

Le plugin .NET pour Sonar est né dans une DSI où il y avait autant de projets Java que de projets .NET. Il y avait une volonté de centraliser les informations pour avoir une vue globale des niveaux de qualité  des projets de la DSI.

Sonar propose un dashboard global qui répond à ce besoin :

Sonar est conçu pour s'intégrer dans une usine de développement logicielle (Hudson/Jenkins ou bien justement TFS). Cette intégration permet une mise à jour des métriques à chaque build !

Chaque mise à jour est sauvegardée et Sonar propose des graphiques montrant l'évolution des métriques dans le temps :

Pour finir

Sonar est l'outil indispensable pour évaluer la qualité des projets d'une DSI au fil de l'eau.

Dans notre prochain article, nous vous montrerons comment mettre en place Sonar pour un projet .NET et comment l'intégrer à un build TFS 2010.

Nous remercions l'équipe de développement du module .NET pour le travail impressionnant qu'ils ont accompli.