Au pays des mille et un rapports Maven
Un article de Agile-Swiss.
L'objectif de cet article n'est pas de faire une présentation du produit de gestion de projet Maven mais de proposer une balade aux pays des mille et un plugins de reporting disponibles. Pour ceux qui ne sont pas très familiers avec Maven, vous trouverez en bas de pages des liens vers la présentation Maven réalisée par Vincent Massol à Javapolis, un tutorial maven et les sites officiels(wiki, jira, jakarta). Enfin pour ceux qui ne jurent que par le contact charnel avec le bon vieux papier, vous pourrez toujours attendre la sortie du bouquin que [Vincent Massol] écrit actuellement pour O'Reilly.
Bien entendu, on peut faire de l'XP sans ces reporting et quand on souhaite commencer à les utiliser il faut que les autres pratiques XP soient en place. Les outils de reporting ne sont qu'une belle cerise sur le gateau. Comme vous allez le voir par la suite, la quasi totalité des reportings existaient bien avant la naissance de Maven , mais Maven offre un cadre général qui n'existait pas jusqu'à maintenant pour les agréger extrêmement rapidement.
Ces rapports ont à mon sens deux intérêts majeurs:
- Ils fournissent des informations à valeur ajoutée pour améliorer la qualité du code: code coverage (Clover, Emma), code smells(FindBugs, Simian, PMD, JDepend), respect des conventions de codage (Checkstyle).
- Ils mettent totalement à nu une application ce qui favorise le sentiment de collective code ownership et oblige les personnes un peu trop possessives à faire le deuil de leur bébé (je ne crois pas être trop caricaturale en disant cela),
Sans entrer dans le détail, une fois que vous avez défini votre projet Maven (c'est à dire grossièrement les dépendances, le répertoire source, le répertoire source des tests unitaires et le repository de gestion des sources), vous lancez simplement la commande :
maven site
et vous obtenez un site web statique contenant l'ensemble des rapports suivants:
Sommaire |
JXR
Ce plugin nous permet de rebondir sur l'article de Didier portant sur l'utilité des commentaires ([To comment or not comment]). Je pense également comme Didier qu'on accorde en entreprise beaucoup, beaucoup trop d'importance à la javadoc. A titre perso, je limiterai son utilisation à la définition des interfaces des librairies. Que ceux qui n'utilisent pas la javadoc pour comprendre rapidement comment utiliser les API java, les commons-lang, les commons-collections, etc... lèvent la main. Seulement, comme le dit Didier la javadoc est toujours une grossière approximation de ce que fait réellement le code. Donc si la javadoc, n'est pas suffisante que faites-vous ?????
Vous consulter les sources très intuitivement grâce au plugin JXR. Vous retrouver un système de navigation identique à la javadoc mais au lieu de lire des commentaires vous êtes au coeur de la matrice et vous y évoluer très facilement grâce aux hyperliens.
- Site du plugin JXR
- exemple:
JUnit
Ce serait faire offense aux participants de ce blog que d'expliquer quoi que ce soit sur ce sujet. Silence, on test...
- Site du plugin JUnit
- exemple:
Checkstyle
Checkstyle est le garant du respect des normes de codage. Si une méthode fait plus de x lignes, si une ligne fait plus de x caractères, si une classe est importée mais non utilisée, si une variable est en majuscule mais non déclarée final, etc... Checkstyle sort de l'ombre et vous met le doigt là où ça fait mal.
ATTENTION: on peut également faire une overdose de checkstyle si tous les filtres sont activés. Checkstyle n'est qu'une mécanique qu'il faut rendre judicieusement intelligente.
- Site du plugin Checkstyle
- exemple 1:
- exemple 2:
PMD
A mi-chemin entre checkstyle et Findbugs, PMD scanne l'ensemble des sources à la recherche d'éventuels problèmes comme:
* Unused local variables * Empty catch blocks * Unused parameters * Empty 'if' statements * Duplicate import statements * Unused private methods * Classes which could be Singletons * Short/long variable and method names
A titre personnel, je trouve ce plugin à la fois trop ou pas assez intelligent car il a justement du mal à trouver sa place entre checkstyle et Findbugs. Si vous avez un avis sur le sujet je suis preneur.
- Site du plugin PMD
- exemple:
Findbugs
Le plugin porte bien son nom, sa mission s'il l'accepte: trouver les bugs potentiels. Pour cela il s'appuie sur une notion de ' bug patterns'. Et oui, on peut implémenter des patterns sans le savoir mais malheureusement les mauvais ;-). Vous trouverez à l'adresse [suivante], l'ensemble des bug patterns que Findbugs sait identifier. On trouve notamment dans cette liste:
* Class implements Cloneable but does not define or use clone method * Comparison of String objects using == or != * Class defines equals() but not hashCode() * Class defines field that obscures a superclass field * Method may fail to close database resource * Method ignores return value * Class is Serializable but its superclass doesn't define a void constructor * Method may expose internal representation by returning reference to mutable object * java.lang.Exception is caught when Exception is not thrown * etc..
- Site du plugin Findbugs
- exemple:
Clover ou jCoverage en version Open-Source
Après avoir jeté un coup d'oeil sur le rapport jUnit vous prenez la direction de la machine à café satisfait et rassuré par votre armée de 400 tests unitaires qui veille aux grains. Vous pouvez dormir sur vos deux oreilles... est-si vrai ? Pas forcément, en effet si 80% de vos méthodes sont testées, il se peut très bien que seulement 50% du code le soit réellement. En effet quand on teste une méthode on ne teste pas systématiquement l'ensemble du code qui la compose (if/then, try/catch, break, switch, etc...). Et bien le code coverage c'est ça: déterminer quelles sont exactement les lignes de code testées. bin oui c'est génial.
JDepend
JDepend vous propose une vue orientée package, et vous permet en une page de mieux comprendre les interactions entre ces packages. Il permet également de détecter les dépendances cycliques entre packages. Je trouve qu'ils ont poussé le concept un peu trop loin avec les mesures des pourcentage d'indépendance, d'abstraction, etc... qui tiennent quelque fois de la théorie de la relativité.
- Site du plugin JDepend
- exemple:
Simian
C'est très simple: Simian recherche pour vous tous les bouts de code dupliqués. Par défaut, une duplication de code est considérée comme telle à partir de 10 lignes semblables. Et en plus, il vous permet d'aller consulter directement les lignes de code concernés en pointant sur les pages générées par... le plugin JXR.
- Site du plugin Simian
- exemple:
Changelog
Ce plugin vous permet de consulter l'historique de l'activité sur votre gestionnaire de source.
- Site du plugin Changelog
- exemple:
Dashboard
Il porte bien son nom: c'est votre tableau de bord général vous offrant une vision agrégée du résultat des différents plugins (junit, pmd, checkstyle, simian, clover, etc...).
- Site du plugin Dashboard
- exemple:
Changes
Ce plugin prend tout son intérêt si couplé avec votre outil de gestion des trackers (comme la référence du marché [Jira]). On part donc du postulat que vous utilisez Jira (si vous travailler sur un projet Open-Source l'utilisation du produit est gratuite), le plugin Maven Jira va aspirer l'ensemble des trackers associés à ce projet, générer un fichier changes.xml, que le plugin Changes va exploiter pour générer à son tour un jolie rapport de toutes les fonctionnalités, corrections de bugs, améliorations compris dans une release.
- Site du plugin Changes
- exemple:
FAQ
Pour terminer sur une note légère, il existe même un plugin vous permettant rapidement de définir une FAQ. En effet, dans une FAQ on doit obligatoirement trouver en en-tête la liste des questions suivie ensuite de la liste détaillée des questions / réponses. C'est très simple mais laborieux à faire quand la FAQ est conséquente. Avec le plugin Maven FAQ vous definissez une seule fois votre couple question / réponse dans un fichier [faq.fml] et le plugin se charge de construire la page FAQ.
- Site du plugin FAQ
- exemple:
Conclusion
Retour sur terre en insistant sur le fait qu'on ne doit pas accorder à un rapport plus de valeur qu'il n'en a réellement. J'entends par là, qu'il n'est pas rare de trouver des équipes informatiques managées par les métriques et ces rapports ne manqueront pas d'éveiller la curiosité chez les décideurs. Autant les métriques portent en elles beaucoup d'informations, autant ces informations ne sont que des indicateurs pour définir une politique de management. Je m'explique:
- si le rapport checkstyle annonce 3000 erreurs, cela signifie-t-il que que le développeur est le dernier des imbéciles ? non. Il y a de forte chance qu'il n'y ait pas eu de définition claire des règles de codage à respecter. Personne n'a peut être informé le développeur que sur tous les IDE dignes de ce nom, il existe désormais une fonction de formattage rapide. On a peut être voulu mettre trop rapidement la barre très haute sur les règles à respecter ce qui a engendrer un désinterêt voir un rejet de la part des développeurs, etc...
- si le rapport findbugs est assez sévère, le développeur est-il fautif ? oui et non. Si le développeur à moins de 2 ans d'expérience java et qu'on ne lui permet pas de progresser au contact de développeurs séniors, arrêtez de chercher les causes.
- si le rapport jUnit est vide, devez-vous vous convertir en snipper ? Je crois surtout que c'est le moment d'envoyer vos développeurs en formation quelques jours pour leur offrir enfin la possibilité de comprendre pourquoi les tests unitaires sont si importants et ce qu'est le Test Driven Developpment. Vous verrez revenir une tout autre équipe.
Bref, on ne doit rien conclure hâtivement de ces rapports mais quel feedback !!!!
Liens externes
- Présentation de Maven à Javapolis par Vincent Massol
- le site maven jakarta
- le site wiki maven
- un tutorial Maven parmi d'autres
- issue tracking maven
