Contrôler la qualité de ses projets avec Sonar

Comme nous l'avons vu, Checkstyle propose plus d'une centaine de règles, et il en va de même avec PMD ou Findbugs (sans compter les règles propres à Sonar). Il est donc souhaitable de n'activer que les règles importantes, et de désactiver les autres. Il est également important de paramétrer certaines règles. Par exemple, Checkstyle permet de vérifier que la longueur maximale d'une ligne n'est pas dépassée. Or, la longueur maximale d'une ligne est variable d'une équipe à une autre, d'un projet à un autre. 80, 120, 150 ? Cette valeur reste à définir au sein de l'équipe.

Il va donc falloir définir convenablement les fichiers de configuration de PMD, Checkstyle et Findbugs. Une bonne idée est de partir de la configuration de Sun ou Sonar par exemple, et de l'adapter à ses besoins. Une très bonne pratique consistera également à appliquer certaines de ces règles dans le formateur intégré à son IDE (Eclipse par exemple), et de partager ce fichier de configuration au sein de l'équipe. Certains IDE permettent également d'appliquer le formatage automatiquement lorsque le fichier est sauvegardé (option de base d'Eclipse 3.2 ou supérieur, sinon un plugin existe pour ça). Cette bonne pratique permet ainsi d'obtenir une plus grande rigueur sur le formatage, et donc le respect de certaines règles de codage.

Pour chaque règle, on peut définir d'une part son activation ou non, et d'autre part son niveau de sévérité parmi cinq niveaux (Bloquant, Critique, Majeur, Mineur, Information). Concrètement, dans l'interface d'administration de Sonar, il est possible de définir ces informations pour chaque règle. Il est également possible de jouer directement avec les fichiers XML...

Lorsque l'on intègre Sonar (ou tout autre outil de qualité), le nombre d'erreurs est généralement très important. Après avoir défini les règles à appliquer, il est préférable de les mettre à des niveaux de sévérité assez faibles, puis d'en sélectionner un petit nombre (5 ou 10 par exemple) qui seront considérées comme obligatoires et donc avec un niveau élevé (Bloquant ou Critique). L'équipe de développement va donc se charger de corriger les violations de ces dernières règles en priorité.

Lors de l'étape 2, un petit nombre de règles de codage ont été définies comme critiques. L'équipe de développement s'est donc attelée à corriger les violations de ces quelques règles. Une fois que ces règles obligatoires ne subissent plus ou presque plus de violations, l'étape suivante va consister à choisir un nouveau petit groupe de règles, pour en augmenter la sévérité. Ces règles seront donc le nouveau point d'intérêt des développeurs, en vue d'améliorer la qualité du code de l'application.

En procédant ainsi, et de façon incrémentale, le nombre de règles critiques va augmenter, et le nombre de violations totales des règles va peu à peu diminuer... En schématisant ce processus, cela nous donnerait quelque chose comme ceci :

Le nombre total de règles (ligne bleu clair) est défini dès le début et reste (à peu près) fixe au cours du temps.
Le nombre total de violations (courbe orange) est très élevé au départ, mais diminue progressivement.
Régulièrement, l'équipe de développement va sélectionner un petit groupe de règles comme étant prioritaires (courbe bleu foncé), et s'occupera alors de résoudre leurs violations. Ce qui explique les variations subies par la courbe rouge, dénombrant le nombre de violations de ces règles principales.

L'inconvénient de la méthode précédemment exposée est que l'instauration d'un contrôle de qualité sur un projet peut aboutir à un très grand nombre d'erreurs (ayant une sévérité faible). Il peut donc être intéressant d'utiliser une variante de cette solution. Cette variante fonctionne de la même façon, mais au lieu de n'augmenter que les règles critiques, elle va également faire varier le nombre total de règles.

Le principe est donc presque le même.

• On commence par choisir un petit nombre de règles critiques (une dizaine ou un peu plus, selon l'état initial du projet), ainsi qu'un autre petit nombre de règles moins importantes (avec une sévérité plus faible donc).
• L'équipe de développement va donner la priorité à la résolution des violations des règles de plus forte sévérité.
• Dès que le respect de ces règles s'approche des 100 %, on se charge de régler les règles moins importantes.
• Dès que ces règles de plus faible sévérité ont un taux de violation inférieur à 20 ou 30 %, on augmente la sévérité de ces règles.
• On définit désormais de nouvelles règles avec une sévérité faible.
• On réitère ainsi, jusqu'à ce que le standard soit atteint.

Cette variante serait plutôt schématisée de cette façon :