Contrôler la qualité de ses projets avec Sonar
Date de publication : 13/09/2008 , Date de mise à jour : 13/08/2009
VI. Méthodologie d'activation des règles
VI-A. Etape 1 : définir les règles de codage
VI-B. Etape 2 : définir les règles obligatoires
VI-C. Etape 3 : faire évoluer le niveau des règles
VI-D. Variante
VI. Méthodologie d'activation des règles
Il est très fréquent que la qualité d'un projet ne soit pas surveillée.
Or, lorsque l'on met en place un outil comme Sonar sur un tel projet, il est à peu près assuré que le nombre d'erreurs soit très important (plusieurs milliers d'erreurs).
Afin de ne pas se décourager (ou pire, de décourager l'équipe de développement) il est préférable de suivre un processus que l'on définira ici.
VI-A. Etape 1 : définir les règles de codage
Comme nous l'avons vu, Checkstyle propose plus d'une centaine de règles, et il en va de même avec PMD.
Il est donc important 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 et de Checkstyle.
Une bonne idée est de partir de la configuration de Sun 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.
VI-B. Etape 2 : définir les règles obligatoires
Sonar permet d'indiquer si une règle est obligatoire ou optionnelle.
Concrètement, dans le fichier Checkstyle, une règle définie comme optionnelle aura une sévérité de niveau warning :
...
<!-- Règle définie comme obligatoire : -->
<module name="SimplifyBooleanExpression">
</module>
<!-- Règle définie comme optionnelle : -->
<module name="SimplifyBooleanExpression">
<property name="severity" value="warning"/>
</module>
...
|
Pour les règles PMD, c'est le niveau de priorité qui définira si la règle est obligatoire ou optionnelle.
La priorité PMD est un entier, qui varie de 1 (grosse erreur) à 5 (petite erreur).
Il est toutefois possible, en tant qu'administrateur, d'éditer directement les règles sur le site Sonar, et changer leur état (obligatoire ou optionnelle).
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 toutes en optionnelles, puis d'en sélectionner un petit nombre (pas plus de 5) qui seront considérées comme obligatoires.
L'équipe de développement va donc se charger de corriger les violations de ces règles.
VI-C. Etape 3 : faire évoluer le niveau des règles
Lors de l'étape 2, un petit nombre de règles de codage ont été définies comme obligatoires.
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, qui l'on passera désormais en obligatoire.
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 obligatoires 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 (courbe bleue claire) 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ébut, mais diminue progressivement.
Régulièrement, l'équipe de développement va sélectionner un petit groupe de règles comme étant obligatoires (courbe bleue foncée), 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 obligatoires.
VI-D. Variante
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 (considérées optionnelles, selon la méthode expliquée plus haut).
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 obligatoires, elle va également faire varier le nombre de règles optionnelles.
Le principe est donc presque le même :
- On commence par choisir un petit nombre de règles obligatoires (pas plus de dix), ainsi qu'un petit nombre de règles optionnelles (par exemple une vingtaine).
- L'équipe de développement va donner la priorité à la résolution des violations des règles obligatoires.
- Dès que le respect de ces règles obligatoires s'approche des 100 %, on se charge de régler les règles optionnelles.
- Dès que ces règles optionnelles ont un taux de violation inférieur à 20 ou 30 %, on rend ces règles obligatoires.
- On définit également de nouvelles règles optionnelles.
- On réitère ainsi, jusqu'à ce que le standard soit atteint.
Cette variante serait plutôt schématisée de cette façon :
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.
