Ce terme est de plus en plus utilisé comme synonyme de « classe Java », ce qui est une erreur. Alors, qu’est-ce qu’un POJO au juste ? Et bien, ma définition en serait : une classe Java sans contraintes particulières.

En fait, il n’y a pas de POJO sans framework. Un framework peut vous demander de sous-classer telle ou telle classe, respecter telle convention de nommage, limiter ci, imposer cela. A l’opposé (et un peu en réaction aux EJB), on parle de POJO quand le framework justement n’impose rien sur vos classes Java : vous développez old-school, classes et interfaces sont conçues librement.

Exemple de framework pas-POJO-du-tout :

« Sous-classez com.framework.AbstractPrintableObject, avec un constructeur public à un paramètre de type com.framework.PrintEnvironment. Ne définissez que des méthodes publiques non synchronisées qui lèvent comme exceptions des sous-classes de com.framework.PrintException. etc… etc… »

Le même, façon j’aime-les-POJO :

« Passez-lui un POJO, le framework d’impression essaiera de découvrir ses getters publics et de construire une représentation textuelle imprimable. »

Je précise que j’écris ça dans un souci d’illustration, loin de moi l’idée de suggérer une quelconque supériorité d’une approche tout-POJO par rapport au framework de grand-papa qui offre un lot de superclasses abstraites. Par exemple, je trouve l’approche « pur-POJOs (ah oui, plus plein d’annotations) » un peu hypocrite… :whistle:

Alors, prenons le prochain ticket d’incident… voilà. bla bla bla… mmmh. OK. Ça doit pas être bien compliqué ça devrait se trouver quelque part dans cette classe, là. Tiens, je l’ai jamais ouverte celle-là. Allons-y, Ctrl+Shift+T, OK, de quoi ça a l’air ? 8O Oh meeerde…

C’est précisément l’effet « rôh merde » qu’essaie de mesurer l’outil Crap4j, via la métrique CRAP (Change Risk Analysis and Predictions), ou bien, en français, l’ohmerditude. Cette traduction en vaut une autre, et puis j’aime bien le suffixe « -itude » .

Ce qui me plaît dans cette métrique, c’est que, pour une fois, on part de la question avant de parler de chiffres. Je n’aime pas l’approche qui consiste à constituer des tableaux de chiffres sans fin, qui certes donnent un air très savant, mais qu’on est bien en peine d’exploiter . A travers l’ohmerditude, dans le but de vérifier qu’un code est maintenable, on essaie de répondre à la question « un développeur va-t’il trouver risqué de modifier ce code lors d’une maintenance ? ». Si oui, on prend le risque que personne ne touche plus à ce code qu’entre deux doigts, le bras tendu et en se pinçant le nez de l’autre main (voir fig. 2 ). Les développeurs vont ajouter tout autour de cette boîte noire des couches et des couches de rustines et contournements de moins en moins maintenables .

Maintenant que vous touchez du doigt tout l’intérêt potentiel de cette métrique, intéressons-nous à son calcul. La formule est un dosage pifométrique de complexité cyclomatique et de couverture de tests. En gros, un code sera « crappy » (ou « ohmerdique » si vous préférez) si il est (1) très complexe et (2) très peu testé. Un code très simple sans test ou un code complexe mais très bien testé seront considérés comme acceptables.

Crap4j mélange donc le nombre de conditions à tester avec la couverture de lignes des tests… mmmmh. bon, on a vu pire. Plus exactement, Crap utilise le taux de lignes non couvertes. Si l’on pose l’hypothèse que les décisions sont uniformément réparties dans les lignes de code, alors cette mesure serait une sorte d’estimation de la quantité de décisions non testées. Malheureusement je ne connais pas d’éléments qui viendraient confirmer cette hypothèse, et ça serait quand même peu fiable.

Quel usage ?

Prise en tant que métrique isolée, cette mesure ne serait pas passionnante. Par contre, je l’utiliserais comme indicateur de testabilité et de possibilité de changement. Selon l’ISO-9126, testability et changeability sont bien des sous-caractéristiques de maintainability, on est bien en élément de réponse à la question initiale. Et comme la norme laisse complètement libre la façon de calculer des indicateurs pour les sous-caractéristiques qualité (ce qui est la façon normative de dire « démerdez-vous on vous donnera pas la formule »), Crap peut être utilisé comme formule de calcul de testabilité « sur étagère », qui présente l’avantage d’être simple à expliquer, rapide à mettre en oeuvre et déjà outillée.

A condition que vous n’ayez pas déjà d’outil de mesure qualité qui vous permette de consolider différentes mesures, et à condition également de calibrer crap4j en fonction de vos exigences, celui-ci peut constituer un premier niveau d’outillage qui vous incitera peut-être à aller plus loin.

On préférera peut-être la version produisant des rapports (via ant, à intégrer à son build continu, donc) que la version plug-in eclipse : le public visé pour cet indicateur de risque qu’un changement soit non testé me semble plutôt le gestionnaire (chef de projet par exemple) que le développeur, qui va probablement garder sous les yeux dans son IDE des règles de codage plus immédiatement « actionnables ».