Détection des codes morts en PHP

Question

J'ai un projet dont le code est très désordonné - beaucoup de doublons et de code mort ici et là.

Il y a quelque temps, la couverture du code par les tests unitaires était nulle, mais maintenant nous essayons d'écrire tout le nouveau code à la manière T.D.D. et de réduire la dette technique en couvrant également l'"ancien" code par des tests unitaires (technique du dernier test).

La complexité de la logique métier est assez élevée et parfois, personne ne peut répondre à la question de savoir si certaines méthodes sont utilisées ou non.

Comment trouver ces méthodes de code mort ? Une journalisation extensive ? Une couverture de test plus élevée ? (Ce n'est pas très facile car les clients veulent que de nouvelles fonctionnalités sortent).

Answer 1

xdebug Les outils de couverture de code de l'UE vous permettent de tester les lignes de code qui sont réellement exécutées, sans avoir besoin de placer des instructions de traçage dans toutes les fonctions/méthodes.

Answer 2

C'est un peu tard maintenant, mais PHPDCD prétend faire cela de manière statique, ce qui devrait vous donner un résultat beaucoup plus informatif que de devoir profiler l'exécution réelle du code avec xprof / xdebug.

Answer 3

Je ne connais pas de moyen de détecter le code qui est complètement inutilisé, cela dépasse peut-être les capacités de tous les outils existants. Mais en ce qui concerne les outils existants, il faut trouver http://phpqatools.org/ pour en avoir un bon aperçu.

• Jusqu'à présent, l'un de mes favoris est phploc, qui décompose votre code d'un point de vue orienté objet et vous donne des détails sur le nombre de classes, le nombre de fonctions, le nombre de tests, la localisation moyenne par fonction et la complexité cyclomatique.

• Mon prochain favori est phpcpd qui est le "détecteur de copier-coller de PHP". Il analyse l'ensemble de votre code source, recherche les signatures communes et vous donne une liste de fichiers avec les numéros de ligne.

• Il y a lots d'autres outils sur cette page, choisissez ceux qui vous sont utiles.

Nous utilisons activement ces outils dans web2projet et dans les deux ans depuis que nous avons bifurqué de dotProject, nous avons abandonné environ 35 % du code de base en le remaniant, en éliminant la duplication (initialement 12 %, maintenant environ 2,5 %) et en structurant généralement mieux les choses. Et c'est en comptant nos 15k+ lignes de tests unitaires. :)

Answer 4

Je recommande de parcourir le système avec xdebug profiler ( http://xdebug.org/docs/profiler ).

Exécutez le système et visualisez les logs avec http://code.google.com/p/webgrind/ et voir physiquement ce qui est appelé.

Answer 5

Voir le Outil de couverture des tests SD PHP . Vous exercez votre code comme bon vous semble, y compris (ou non) en exécutant des suites de tests comme bon vous semble. À la fin de l'exécution, vous pouvez voir un affichage du code qui a été exécuté (il y a des captures d'écran sur le site web). Le code qui n'est pas exécuté peut être mort, et nécessite une analyse plus poussée de votre part, mais si vous exercez bien le système, le code non exécuté est soit des gestionnaires d'erreurs, soit des choses vraiment mortes. L'outil PHP Test Coverage ne nécessite pas tout à votre serveur PHP.

Le site SD CloneDR trouve le code dupliqué dans de très grandes bases de code source. Il est sensible au langage (couvrant C, C++, Java, C#, Ada, Fortran ainsi que PHP4 et PHP5) et ne se laisse pas tromper par les changements de formatage, d'espacement ou la présence ou l'absence de commentaires. Il détecte les clones de copies exactes et les clones presque parfaits. Le site Web présente des exemples de rapports de clonage pour plusieurs langues.