web-dev-qa-db-fra.com

Comment lire / améliorer l'index C.R.A.P calculé par PHP

Je viens de commencer à travailler avec PHPUnit et ses rapports de couverture de code colorés. Je comprends tous les chiffres et pourcentages sauf un: l'indice C.R.A.P. Quelqu'un peut-il m'offrir une explication solide de ce que cela signifie, comment l'analyser et comment l'abaisser?

phpunit-testingphpunit
71
Levi Hackwith

@ Toader Mihai a offert une explication solide. (+1 de ma part)

Comment l'abaisser:

Écrire du code moins complexe OR écrire du code mieux testé. (Voir le graphique ci-dessous)

Code mieux testé?

Dans ce contexte, cela signifie simplement: une couverture de code plus élevée et se traduit généralement par l'écriture de plus de tests.

Code moins complexe?

Par exemple: Refactorisez vos méthodes en plus petites:

// Complex
function doSomething() {
    if($a) {
        if($b) {
        }
        if($c) {
        }
    } else {
        if($b) {
        }
        if($c) {
        }
    }
}

// 3 less complex functions
function doSomething() {
    if($a) {
        doA();
    } else {
        doNotA();
    }
}

function doA() {
    if($b) {
    }
    if($c) {
    }
}

function doNotA() {
    if($b) {
    }
    if($c) {
    }
}

(juste un exemple trivial, vous trouverez plus de ressources pour cela, je suis sûr)

Ressources supplémentaires:

Tout d'abord, permettez-moi de vous fournir quelques ressources supplémentaires:

Article de blog des créateurs sur l'index de la merde

juste au cas où: Explication de la complexité cyclomatique . Des outils comme PHP_CodeSniffer et PHPMD vous indiqueront ce numéro au cas où vous voudriez le savoir.

Et bien que ce soit à vous de décider quel nombre est "ok", un nombre souvent suggéré (c'est-à-dire un peu élevé) est un indice de merde de 30 résultant en un graphique comme celui-ci:

alt text (Vous pouvez obtenir le fichier .ods ici: https://www.dropbox.com/s/3bihb9thlp2fyg8/crap.ods?dl=1 )

104
edorian

Fondamentalement, il veut être un prédicteur du risque de changement pour une méthode.

Il y a deux facteurs:

  • complexité du code de la méthode (cyclomatic complexity) alias combien de chemins de décisions existent dans ladite méthode: comp(m).
  • comment testable est cette méthode (via des tests automatisés, fournis par un outil de couverture de code). Fondamentalement, cela mesure le nombre de décisions dans ledit code qui peuvent être testées automatiquement.

Si la méthode a une couverture de 100%, le risque de changement n'est considéré comme équivalent qu'à la complexité de la méthode: C.R.A.P.(m) = comp(m).

Si la méthode a une couverture de 0%, le risque de changement est considéré comme un polinôme du second degré dans la mesure de complexité (le raisonnement étant que si vous ne pouvez pas tester un chemin de code en le modifiant, il augmente le risque de rupture): C.R.A.P.(m) = comp(m)^2 + comp(m)

J'espère que cela vous aidera.

Je viens de remarquer que je ne donne que la demi-réponse (la partie lue). La façon de l'améliorer devrait être assez claire si vous comprenez le raisonnement de l'index. Mais une explication beaucoup plus claire est donnée dans @ réponse edorian .

L'histoire courte est la suivante: écrivez des tests jusqu'à ce que vous ayez une couverture de près de 100%, puis refactorisez les méthodes pour diminuer la complexité cyclomatique. Vous pouvez essayer de refactoriser avant d'avoir des tests, mais selon la complexité réelle de la méthode, vous risquez d'introduire une rupture si vous ne pouvez pas raisonner (en raison de la complexité impliquée) toutes les conséquences du changement que vous faites.

61
Mihai Toader