Simplifier le code de vos beans Java à l'aide de Commons Lang, Guava et Lombok

[sekaijin]

Envoyé par thierryler

Perso, durant mes essais, ça a été invisible

chez moi aussi

[gencoforlife]

Bonjour,

Merci également pour cet article qui est très bon.

On doit ensuite faire un refresh (touche F5) dans Eclipse pour faire apparaitre Guava (et ses dépendances) dans la liste des bibliothèques référencées.

Pour la première fois où cette phrase apparait : On doit ensuite faire un refresh (touche F5) dans Eclipse pour faire apparaitre Apache Commons Lang (et ses dépendances) dans la liste des bibliothèques référencées.

[natha]

Envoyé par Nemek

Ensuite les outils utilisés par Sonar proposent TOUS un système d'exclusion. En ciblant correctement, on peut avoir des "bonnes" stats.

J'ai travaillé sur des projets où les entités censées contenir uniquement des getters/setters étaient ignorées des analyses SONAR. Par curiosité j'ai enlevé le filtre et quelle ne fut pas ma surprise d'avoir des dépendances cycliques de packages, des dizaines de violations supplémentaires, etc.
C'est toujours compliqué de trouver le juste milieux.

[Khaled.Noordin]

Salut a tous
bon bah je vais passer pour un troll, mais pourquoi ne pas simplifier votre code en utilisant groovy et gmaven
La dernière fois que j'ai utilisé lombok intellij ne voyait pas la génération des méthodes au runtime, et les equals et hashcode étaient peu customisable.

En tous cas merci pour l'article

[dark.jabberwock]

Merci pour cet article. Je découvre plein de choses d'un coup...

Le seul truc qui me dérange est le fait de devoir modifier l'IDE avec Lombok. Sinon c'est clair que ça peut être un sacré gain de temps...

[Robin56]

Envoyé par dark.jabberwock

Le seul truc qui me dérange est le fait de devoir modifier l'IDE avec Lombok. Sinon c'est clair que ça peut être un sacré gain de temps...

Je ne sais pas si l'on peut parler de gain de temps car un "Generate getters and setters" est assez rapide d'origine. Je parlerais plutôt de gain de lisibilité et de qualité de code.

[dark.jabberwock]

En fait Robin56 je pensais à un gain de temps si l'on utilise l'annotation @Data. Car au niveau d'Eclipse même avec les raccourcis clavier, c'est plus court d'écrire 5 lettres en annotations que de générer via l'IDE les différents éléments générés par @Data. Par contre le "sacré gain de temps" est largement exagéré de ma part j'en convient.

Après effectivement c'est surtout un gain de lisibilité et pour moi une certaine qualité de code notamment au niveau equals et hashCode.

Réflexion à part, en pensant aux métriques de Sonar (je ne connais que peu le paramétrage de l'outil), on nettoie peut être un peu la partie nombre de ligne de code et pourcentage de commentaire. A moins que pour ces informations, on puisse également exclure les classes de certaines vérifications. Là dessus qu'en pensez-vous ?

[Nemek]

Envoyé par natha

J'ai travaillé sur des projets où les entités censées contenir uniquement des getters/setters étaient ignorées des analyses SONAR. Par curiosité j'ai enlevé le filtre et quelle ne fut pas ma surprise d'avoir des dépendances cycliques de packages, des dizaines de violations supplémentaires, etc.
C'est toujours compliqué de trouver le juste milieux.

Je te l'accorde ! D'ailleurs à l'inverse sur mes projets j'ai des classes bêtes et méchantes (type utilitaire) qui sont marqués en Hot Spot (pas sûr du nom). De même, les classes un peu critique au sens de l'analyse statique (beaucoup de code) remonte rapidement alors que d'autres classes avec moins code mais très critique vont rester dans le bas du tableau, derrière des POJO, parce qu'elles ont peu de code.

Cependant, dans ton cas, il semble surtout que ce soit un problème d'identification des exclusions. Je suggère fortement aux architectes/concepteurs/dev leader de définir clairement des règles aussi bien de codage que d'organisation des packages ou des règles précises de nommage.
Ca permet dans tous les cas à quelqu'un de comprendre là où il se trouve (lors de la navigation / recherche) et où il doit chercher dans le code.

Autre point, certaines règles ne devraient pas avoir d'exclusion (en tout cas, je ne vois pas de raison), et je pense dans ton cas, à l'analyse des dépendances.

Enfin, cela me donne une idée pas si mal, inclure des analyses spécifiques pour ce qui a été exclu. Je ne sais pas si cela est possible avec Sonar ... Par exemple, vérifier qu'il s'agit de simple POJO.

Envoyé par Robin56

Je ne sais pas si l'on peut parler de gain de temps car un "Generate getters and setters" est assez rapide d'origine. Je parlerais plutôt de gain de lisibilité et de qualité de code.

En maintenance, ca fait toujours gagner pas mal de temps et éviter des erreurs bêtes comme supprimer des getter/setter mais pas l'attribut et pour le couple equals/hashCode j'en parle même pas !

Envoyé par dark.jabberwock

Réflexion à part, en pensant aux métriques de Sonar (je ne connais que peu le paramétrage de l'outil), on nettoie peut être un peu la partie nombre de ligne de code et pourcentage de commentaire. A moins que pour ces informations, on puisse également exclure les classes de certaines vérifications. Là dessus qu'en pensez-vous ?

Vu qu'il n'y a pas de code, ces métriques ne sont pas "impactées". Comme je le mentionnai ca ne peut qu'augmenter la justesse des métriques.
Exemple, 10 erreurs sur 100 lignes utiles ou sur 125 dont 25 inutiles, ca donne 10% ou 8% d'erreur. Si on considère qu'il y a beaucoup de POJO, surtout avec des framework comme Struts (Forms) / JSF (Backing bean) / JPA (Persistent class) / J2EE (EJB), il doit y avoir un paquet de lignes de codes non critiques.