Quels outils de métrique Java utilisez-vous ?

Bonjour,

Ce petit sondage est également l'occasion de partager vos expériences et usages. Par exemple :

:fleche: dans quel contexte technique vous les utilisez (maven, ant, EDI, autre ? )
:fleche: dans quelle démarche de développement (cycle, XP, norme qualité, autre ? )
:fleche: quel bénéfice (auprès du client, développeur, maintenance, évolution, autre ? )
:fleche: quel conseil ?
:fleche: quels serait vos souhaits, si vous voudriez des tutoriaux sur ce sujet dans dvp (ou les écrire, nous sommes toujours à la recherche de contributeurs), etc, etc, etc.

Voici les sites des outils cités : Cobertura, CheckStyle, PMD/CPD, Findbugs, JDepend, JLint, Cast

Vous pouvez voter pour plusieurs produits.

Sur ce sujet, vous pouvez consulter Les outils de gestion de la qualité d'un projet Java et leur intégration à Maven 2, Calculer les métriques de vos projets avec Metrics, Analyse de la qualité du code Java avec JDepend 2.7, :faq: Maven Comment analyser les métriques avec JDepend ?

:fleche: Outils :
Selenium, cobertura
:fleche: dans quel contexte technique vous les utilisez (maven, ant, EDI, autre ? )
Maven,NetBeans,Hudson
:fleche: dans quelle démarche de développement (cycle, XP, norme qualité, autre ? )
Nos projets sont en continuel developpement (domaine de la recherche).
:fleche: quel bénéfice (auprès du client, développeur, maintenance, évolution, autre ? )
Aucun benefice particulier, juste reconforter le client et le patron.
:fleche: quel conseil ?
Il ne faut pas que ces outils vous empeche de travailler ni contraigne votre code a respecter des patterns ou des mises en forme douteuses, ca ne doit pas prendre plus de 5% de votre temps.

:fleche: Outils :
PMD, Checkstyle, jDepend

:fleche: dans quel contexte technique vous les utilisez (maven, ant, EDI, autre ? )
Checkstyle intégré à Eclipse, PMD et jDepend en ligne de commande avec sortie CSV

:fleche: dans quelle démarche de développement (cycle, XP, norme qualité, autre ? )
Checkstyle dans tous les projets, PMD et jDepend en audit de code ou revue d'architecture

:fleche: quel bénéfice (auprès du client, développeur, maintenance, évolution, autre ? )
L'outil est plus objectif que le consultant, il n'est pas discutable ; ce qui est évidemment discutable puisque c'est moi qui fais le paramétrage. Par contre, d'un point de vue psychologique, ça permet de ramener plus facilement les fortes têtes et contestataires dans le droit chemin.

:fleche: quel conseil ?
- Checkstyle doit être intégré dès le début du projet.
- Sélectionner les règles pertinentes (et rentables)
- Associer des diagrammes UML de packages aux résultat de jDepend

En plus de ce qui a été dit précédemment, je voulais ajouter que j'utilise personnellement Sonar, qui agglomère les résultats de checkstyle, cobertura / clover, findbugs, pmd...

:fleche: Contexte technique :
Bamboo pour ordonnancer des tests et présenter les métriques, maven pour jouer les builds et eclipse pour la partie IDE
:fleche: dans quelle démarche de développement (cycle, XP, norme qualité, autre ? )
projets géré par méthodologie agile, cycles de développement court et itératif qui nécessitent des phases de non régression automatisé.
:fleche: quel bénéfice (auprès du client, développeur, maintenance, évolution, autre ? )
Grand bénéfice sur la maintenance. L'utilisation des outils permet de mesurer les évolutions qualitatives du code (PMD, checkstyle, findbugs) et quantitative (clover indique le nombre de lignes de code et sa couverture).
La tracabilité des commits sous svn et la liaison entre commit et fiche JIRA et builds bamboo permet de mettre le doigt rapidement sur le bout de code fautif ainsi que la motivation qui a entrainé la modification.
Grand bénéfice pour le développeur qui est rassuré vis à vis de la non régression et qui sait travailler dans un cadre bien délimité. C'est aussi un confort puisque chaque développeur utilise les mêmes conventions et cela améliore la facon de reprendre le code d'un autre développeur.
Les tests unitaires associés à la couverture de code permettent de mettre en évidence le code à risque ainsi que le code mort.
Bénéfice clients faible, nous ne communiquons que très peu sur nos méthodes.
:fleche: quel conseil ?
L'effort de mise en place est important mais nécessaire. Que ce soit sur un projet "historique" existant ou un nouveau projet, les métriques sont un facteur de qualité.
Evidemment il faut les associer aux développeurs et leur en montrer le bénéfice. La mise en place n'est pas uniquement technique, c'est aussi une formation continuelle des équipes afin de les encourager à travailler avec.

En voyant d'ailleurs une des réponses plus haut, (désolé eclesia si je prends ta réponse, mais elle est significative), on voit clairement que l'effort de communication n'a pas été fait puisque le développeur n'est pas convaincu des outils qu'il utilise et n'y voit aucun bénéfice et conseille d'ailleurs d'y passer peu de temps.

C'est au responsable qualité s'il y en a un et au manager de mettre en évidence les apports positifs de ces techniques et ce n'est pas toujours évident puisque c'est très consommateur en temps pour parfois peu de résultats directement visibles (mais les résultats sont bien la dans le temps).

Bonjour,

J'utilise Sonar. Trés pratique pour repérer les copié collé ainsi que les classes trop complexes qui doivent etre refactorisés.
Il permet aussi de voir facilement la couverture de test de chaque classe.

David Gimelle
Développeur J2EE
blog: http://getj2ee.over-blog.com

perso findbugs dans Eclipse ou en standalone, juste pour vérifier que j'ai pas fait d'erreurs grossières une fois de temps en temps pendant le developpement d'un projet

Citation:

---

Envoyé par hugo123

En voyant d'ailleurs une des réponses plus haut, (désolé eclesia si je prends ta réponse, mais elle est significative), on voit clairement que l'effort de communication n'a pas été fait puisque le développeur n'est pas convaincu des outils qu'il utilise et n'y voit aucun bénéfice et conseille d'ailleurs d'y passer peu de temps.

---

De mon point de vue, il y a une part de ses outils qui sont fait pour les non-javaiste et les debutants java, comme les corrections de nom de methode, de variable et de porté. C'est sans doute tres utile afin de garantir un minimum de qualité et de rigueur dans le code.
Toutefois tout le monde n'est pas comme ca, quand je ne met pas de "get" devant un accesseur, j'en connais la raison et je sais ce que je fais. de meme pour l'usage des final et des bloc if else sans les {} pour raison de lisibilité. Bref plein de raison du genre.

Pour imager :
On ne demande pas a quelqu'un de peler une pomme de terre avec un epluche legume alors qu'il le fait plus vite depuis 5ans avec un couteau.
(car il faut l'admettre, ces outils ralentissent les machines et prennent du temps de mise en place)

Ce n'est pas une question de communication, c'est savoir faire son métier.

Tout ses outils, tout comme les designs patterns sont des aides et des recomandations, en aucun cas des obligations et en aucun cas des standards (si ca le devient nous ne seront plus que machine a taper vivante, de la marchandise consommable)

C'est malheureusement ce que nous sommes. Sans vouloir dénaturer notre profession, le temps de l'informaticien artisan/artiste est un peu révolu.
Aujourd'hui il faut travailler dans des sociétés qui pratiquent l'offshore, qui ont des turnovers importants et des niveaux très hétérogènes dans les équipes.

Dans un contexte d'artisanat et individuel, je te rejoins à moitié sur ton analyse, effectivement on peut travailler avec ces normes personnelles depuis plusieurs années et être très productif.

Dans un contexte de travail en équipe, les standards apportent un plus indéniable pour la compréhension, qui plus est si on prend des normes internationales (exemple la convention java beans, les normes de codage sun etc...).
Qui plus est, ces outils font plus que détecter que la variable n'a pas un nom camelcase ou que la méthode bidule dépasse les 100 lignes. Ils sont capable de détecter grossièrement des erreurs de synchro, des problèmes de copier coller, des complexités algorithmiques trop importantes (qui peuvent être justifiés mais pas toujours) etc...

Pour prendre certain de tes exemples :
- quand je ne met pas de "get" devant un accesseur, j'en connais la raison et je sais ce que je fais.
=> toi tu le sais, et sans doute que tu as analysé ton cas d'usage qui te permet de dire que ce n'est pas utile. Par contre le débutant, voire même la personne confirmé qui tentera d'utiliser ton bean plus tard avec jaxb ou hibernate ne va pas comprendre pourquoi son attribut n'est pas modifié et il mettra longtemps avant de voir que ca vient du fait que ca ne respecte pas le standard java beans

- bloc if else sans les {} pour raison de lisibilité
=> La encore, le développeur sait très bien qu'il peut s'en passer que c'est plus lisible et que cela ne comporte pas de bugs. Mais la personne qui repassera dessus dans 2 ans et qui utilisera un éditeur qui aura mangé les indentations ou qui n'aura juste pas pris son litre de café et aura rajouté une ligne en dessous ou en dessus en pensant la prendre dans le if (ou pas), aura bien des surprises.


Bref, ce post est peut être a moitié adapté pour ce type de discussion et pourrait être poursuivi ailleurs. Ce que je souhaitais souligner de facon constructive (sans cibler qui que ce soit), c'est que justement la mise en place de ces outils n'est pas qu'une question de départager les personnes qui savent faire leur métier et les autres. Les experts ont tout autant besoin de ce type d'outils pour se concentrer sur leur coeur de métier.
Le conseil plus haut visait justement a souligner l'importance de la communication pour faire accepter ces outils plutôt que les imposer, ce qui donne généralement des résultats contre productifs car on ne voit que le coté consommateur de temps.
Visibiblement j'ai l'impression que c'est ton cas ;)

Evidemment cela n'est vrai que dans les équipes qui font la maintenance de leur propre code (ce qui n'est pas toujours le cas) et qui ont une longévité supérieure à 1 ans sur le même projet, dans le cas contraire il sera très difficile de prouver l'intérêt de l'outils sur le long terme.

:fleche: Outils :
PMD, Checkstyle, jDepend, FindBugs, Sonar, Hudson (serveur d'intégration continue)

:fleche: dans quel contexte technique vous les utilisez (maven, ant, EDI, autre ? )
Checkstyle intégré à Eclipse également, tous les autres sont passés automatiquement chaque nuit par Hudson (ou chaque week-end sur les très gros projets nécessitant un temps de compilation important)

:fleche: dans quelle démarche de développement (cycle, XP, norme qualité, autre ? )
Sur tous les projets, afin d'assurer un bon niveau de qualité de code (et former les développeurs en explicitant les raisons des erreurs remontées par les outils de qualimétrie)

:fleche: quel bénéfice (auprès du client, développeur, maintenance, évolution, autre ? )
pour le client, l'assurance de la qualité de ce qui est livré (encore que les outils ne font pas tout...)
pour le développeur, la formation : à force d'avoir des avertissements (et leurs explications... sinon c'est stérile) et de devoir les corriger, ils apprennent à mieux coder
pour la maintenance, le coût et le temps qui est réduit : on débuggue bien plus facilement une méthode avec javadoc et commentaire, décomposée en sous-méthodes élémentaires qu'un pavé procédural de 200 lignes sans commentaires (et je n'exagère pas... c'est du vécu)
pour l'évolution... c'est plus délicat : certes, les outils aident, mais c'est plus l'architecture (utilisation d'interfaces, etc.) qui assure l'évolutivité d'une application. Et les outils ne font pas (encore ?) de vérification de l'architecture

:fleche: quel conseil ?
- Checkstyle doit être intégré dès le début du projet... corriger un projet sinon est bien trop coûteux
- Ne pas appliquer toutes les règles... certaines sont inutilement énervantes à mettre en place (par exemple, je ne vois pas spécialement l'intérêt d'interdire l'indentation par tabulation au profit des espaces)
- Si les outils ne sont pas mis en place dès le début du projet, il faut les intégrer petit à petit (en mettant d'abord les règles les plus importantes, puis en les rajoutant quand le projet avance) pour ne pas avoir 17562 violations de règles d'un coup !

Citation:

---

Envoyé par hugo123

Dans un contexte de travail en équipe, les standards apportent un plus indéniable pour la compréhension, qui plus est si on prend des normes internationales (exemple la convention java beans, les normes de codage sun etc...).

---

Tout a fait d'accord.

Citation:

---

Envoyé par hugo123

- quand je ne met pas de "get" devant un accesseur, j'en connais la raison et je sais ce que je fais.
=> toi tu le sais, et sans doute que tu as analysé ton cas d'usage qui te permet de dire que ce n'est pas utile. Par contre le débutant, voire même la personne confirmé qui tentera d'utiliser ton bean plus tard avec jaxb ou hibernate ne va pas comprendre pourquoi son attribut n'est pas modifié et il mettra longtemps avant de voir que ca vient du fait que ca ne respecte pas le standard java beans.

---

ce n'est effectivement pas la norme java bean, ce cas m'arrive en fait tres souvent, quand j'ai des classes offrant des collections vivante en acces.
Par exemple, au lieu d'avoir un :

Code:

---

1 2 3 4 5

setUsers(List<User> users); List<User> getUsers(); // j'ai ceci : List<User> users();

---

Horrible vas tu me dire, on accede a la liste direct, probleme de synchronisation droit devant. Sauf que si tu es un bon developpeur, tu ira lire la javadoc et tu sauras qu'il s'agit d'un objet synchronisé d'un tout autre type qui se cache derriere et qui ne fait qu'offrir une interface de type List.
Ca parait deroutant quand on est habitué aux bien beaux et bien jolies patterns, mais c'est du java parfaitement legal.

Quand a JaxB tu as mon avis sur cette horreur :aie: ici :
http://www.developpez.net/forums/d62...professionnel/
(le fait qu'il en resort un 50-50 montre que ce n'est pas une API de reference)

Citation:

---

Envoyé par hugo123

- bloc if else sans les {} pour raison de lisibilité
=> La encore, le développeur sait très bien qu'il peut s'en passer que c'est plus lisible et que cela ne comporte pas de bugs. Mais la personne qui repassera dessus dans 2 ans et qui utilisera un éditeur qui aura mangé les indentations ou qui n'aura juste pas pris son litre de café et aura rajouté une ligne en dessous ou en dessus en pensant la prendre dans le if (ou pas), aura bien des surprises.

---

Je pense a des cas comme :

Code:

---

1 2 3 4 5 6 7 8

if(var==null) throw new NullPointerException(...); //ou encore if( var.equals(...) ) varN = ... ; else if( var.equals(...) ) varN = ... ; else if( var.equals(...) ) varN = ... ; else if( var.equals(...) ) varN = ... ; else varN = ... ;

---

l'usage des {} dans beaucoup de petit cas rend le code moins lisible et 2 à 3 fois plus étalés (et donc encore moins lisible).

Citation:

---

Le conseil plus haut visait justement a souligner l'importance de la communication pour faire accepter ces outils plutôt que les imposer, ce qui donne généralement des résultats contre productifs car on ne voit que le coté consommateur de temps.
Visibiblement j'ai l'impression que c'est ton cas

---

C'est effectivement mon cas mais je ne denigre pas tout les outils, loin de la, c'est surtout les patterns, la syntaxe, la mise en forme et les cas particuliers qui font faussement baisser le verdict de "qualité".

ps: si le debat prend trop d'ampleur, je ferais un nouveau topic ;)

héhé, pour jaxb c'est plutot 50% pour / 15% contre et 30% ne sais pas (je viens de voter) mais avec 6 votes c'est pas très représentatif ^^

Bon sinon sur le reste je ne reviendrais pas, je pense que ces outils c'est avant tout une question de conventions accepté par une équipe (et non imposé). Si nous travaillions ensemble je tenterais de t'en convaincre en pause café, c'est de le meilleur endroit pour les discussions informelles ^^

Mais pourquoi pas un petit article dvp qui pourrait être intéressant pour expliciter certaines de ces normes

Promis le prochain message c'est en PM pour éviter de polluer le topic :)

Pourtant je la trouve intéressante votre discussion ! C'est le genre de question auxquelles on fait face lorsqu'on met en place ces outils...

Perso j'active dans le CheckStyle l'obligation des { } dans les if/else !
Je trouve beaucoup plus lisible un code indenté que cette horreur (sans offense, c'est une appréciation personnelle) :

Code:

---

1 2 3 4 5 6 7

if(var==null) throw new NullPointerException(...); //ou encore if( var.equals(...) ) varN = ... ; else if( var.equals(...) ) varN = ... ; else if( var.equals(...) ) varN = ... ; else if( var.equals(...) ) varN = ... ; else varN = ... ;

---

D'autant plus qu'il suffit qu'un petit malin fasse Ctrl+Shift+F sur ta classe pour indenter selon la configuration Eclipse et on se retrouve avec :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

if(var==null) throw new NullPointerException(...); //ou encore if (var.equals(...)) varN = ... ; else if( var.equals(...)) varN = ... ; else if( var.equals(...)) varN = ... ; else if( var.equals(...)) varN = ... ; else varN = ... ;

---

Et je ne connais pas un débutant voire expert qui ne soit jamais tombé dans le panneau du if/else sans { }.


Chez nous pour la mise en place des normes j'ai pu le faire quand l'équipe était encore jeune (comprendre peu de personnes). J'ai mis en place un certains nombre de règles en suivant les standards Sun et mis au vote les règles. Certaines ont été acceptées sans problèmes, d'autres ont suscité débat, mais maintenant notre code est vraiment uniforme (ce qui évite également de générer trop de diff lors des commits SVN pour de la mise en forme...).


Ah oui, à noter qu'Eclipse 3.4 est maintenant capable de mettre automatiquement les accolades sur les blocs if/else lorsqu'il sont manquants via le Ctrl+Shit+F.
On se retrouve donc directement avec :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

if(var==null) { throw new NullPointerException(...); } //ou encore if (var.equals(...)) { varN = ... ; } else if( var.equals(...)) { varN = ... ; } else if( var.equals(...)) { varN = ... ; } else if( var.equals(...)) { varN = ... ; } else { varN = ... ; }

---

Ce qui est quand même le plus lisible. Cependant ce type de code dénote souvent un problème d'algorythmie sur le fond. Les if/else en cascade devraient être rares.