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