2010-03-01 3 views
3

Je viens d'hériter d'un projet, et on m'a dit qu'un dossier entier, "includes /" devait être supprimé en raison de problèmes de licence - Nous n'avons pas le droit de redistribuer les fichiers dans ce dossier, nous devons donc réduire nos dépendances et corriger les interruptions. On m'a dit "Moins de 5% des lignes de ce dossier sont même appelées par notre programme", mais je n'ai aucun moyen de le vérifier.Supprimer efficacement de gros morceaux de PHP

Il y a environ 50 fichiers dans le dossier, chacun avec quelques centaines de lignes de code. Aucun test unitaire n'est actuellement en place. Il y a un fichier principal, include.php, require()s tous les 49 autres fichiers, donc je ne peux pas simplement grep pour n'importe quel fichier en faisant import() sur includes/.*.

C'est à peu près autant de détails que j'ai vraiment compris à ce stade. J'ai passé toute la semaine à lire les fichiers dans le dossier includes/et il ne sera pas difficile de réécrire tout cela, mais j'ai du mal à décider par où commencer. J'ai essayé de supprimer le dossier et de réparer lentement les choses qui cassent, mais j'ai peur que cette route me fasse manquer certaines fonctions cruciales dans ma réécriture.

Quelqu'un peut-il me diriger dans une direction pour commencer? Existe-t-il des outils qui simplifieront ce processus? Je regarde xdebug en ce moment, mais je ne sais pas exactement comment je l'utiliserais pour ça.

Répondre

2

Vous voudrez peut-être chercher "couverture de code php". Cela devrait vous aider à comprendre quel code est utilisé. Par exemple, cela apparaît comme cela pourrait aider:

http://www.xdebug.org/docs/code_coverage

+0

C'est exactement ce que j'aimerais faire. Mon approche finale sera, bien sûr, de supprimer le dossier, mais le profilage pour la couverture de code me donne une vue complète à 100% de ce que je vais affecter avant de mettre quelque chose en place. Merci beaucoup! – linked

0

Votre approche initiale est pas mal du tout. Il est certainement un endroit raisonnable pour commencer:

  1. supprimer ce code qui n'est pas autorisé.
  2. Essaye d'exécuter ce qu'il reste.
  3. si les choses se cassent: créez un stub pour une méthode qui est maintenant manquante, et réglez-la pour retourner une valeur "default" raisonnable pour le moment.
  4. goto 2.

Ensuite, Détaillez toutes les choses qui ont été portés disparus, et de faire un calendrier raisonnable pour réimplémenter chaque chose.

0

Je voudrais commencer par grepping pour les fichiers qui font référence à include.php. Vérifiez à travers eux si elles sont gérables, un par un. Ensuite, je grep pour chacune des fonctions dans les fichiers/include/* php. Voyez s'ils sont appelés n'importe où, trouvez-les, remplacez-les. Comme PHP est dynamiquement typé, je ne pense pas qu'il y aura un outil pour cela.

(attend avec impatience quelqu'un pour me prouver que j'ai des tâches semblables tout le temps ...)

0

Voir SD PHP Test Coverage Tool. Il fournira une vue visuelle du code réellement exécuté, ainsi qu'un rapport sur les parties des fichiers utilisées (y compris "no parts", ce qui indique que le code est susceptible d'être supprimé).

Il ne nécessite aucune modification manuelle de votre code, ni aucun test unitaire pour l'exécuter.

0

Pour répondre à ma propre question, j'ai fini par utiliser le profileur xdebug pour faire le travail, comme je l'étais initialement (après la suggestion d'un ami m'a incité à jeter un second coup d'oeil).

Dans mon /etc/php5/apache2/conf.d/xdebug.ini (sur ubuntu 9.10), je mis xdebug.profiler_enable=1 et xdebug.profiler_output_dir=/var/log/xdebug/, puis chargé les fichiers cachegrind résultants avec KCacheGrind et juste couru une recherche sur les noms de fichiers pour " comprend/".

Maintenant j'ai une montagne de travail devant moi pour enlever tout cela, mais au moins j'ai un bon aperçu de ce que je vais modifier!