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 ?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”.