Nettoyage énorme Perl Codebase

Je travaille actuellement sur une application web d'environ 15 ans.Nettoyage énorme Perl Codebase

Il contient principalement des scripts CGI perl avec modèles HTML :: Template.

Il a plus de 12 000 fichiers et environ 260 Mo de code total. J'estime que pas plus de 1500 scripts perl sont nécessaires et je veux me débarrasser de tout le code inutilisé.

Il n'y a pratiquement aucun test écrit pour le code.

Mes questions sont les suivantes:

Connaissez-vous un module CPAN qui peut me aider à obtenir une liste de seulement use d et require modules d?
Quelle serait votre approche si vous voulez vous débarrasser de tout le code supplémentaire?

Je pensais aux approches suivantes:

essayer de passer outre les use et require perl builtins avec ceux qui sortie le nom du fichier chargé dans un emplacement spécifique
override la warnings et/ou strict modules import fonction et la sortie du nom de fichier à l'emplacement spécifique
étudier le module Devel::Cover perl et d'adopter la même approche et d'analyser le c ode lorsque vous faites le test manuel au lieu de tests automatisés
remplacer l'exécutable perl avec un personnalisé, qui se connectera chaque nom de fichier, il lit (je ne sais pas comment faire encore)
une utilisation créative de lsof (!?)

Source

2012-05-25 Tudor Constantin

Mon approche serait de commencer par écrire les tests avant de toucher un code, comme toujours lors d'une maintenance majeure. –

Mes estimations sont que 80% du code n'est pas utilisé/nécessaire - il n'est pas financièrement possible d'écrire des tests pour l'ensemble du code. –

@TudorConstantin - N'écrivez pas de tests unitaires pour le CODE. Rédiger des tests fonctionnels pour les cas d'utilisation de l'application. – DVK

Devel::Modlist peut vous donner ce dont vous avez besoin, mais je ne l'ai jamais utilisé.

Les quelques fois que j'ai eu besoin de faire quelque chose comme ça, j'ai opté pour l'approche plus brutale de l'inspection %INC à la fin du programme.

END { 
    open my $log_fh, ...; 
    print $log_fh "$_\n" for sort keys %INC; 
}

Source

2012-05-25 15:02:32

Sweet. Faites de $ log_fh une fonction de $ 0 et laissez les choses tourner un peu ... – gsiems

Il y a plus d'une façon de le faire - vos deux manières semblent justes pour mon besoin. En ce moment je travaille sur l'approche 'END {...}' et ça marche bien - grand merci –

en première approximation, je voudrais simplement courir

egrep -r '\<(use|require)\>' /path/to/source/*

Ensuite, passer quelques jours nettoyer la sortie de cela. Cela vous donnera une liste de tous les modules utilisés ou requis.

Vous pouvez également jouer avec @INC pour exclure certains chemins de bibliothèque. Si vous essayez de déterminer le chemin d'exécution, vous pouvez exécuter le code via le traqueur avec 'trace' (ie 't' dans le débogueur) activé, puis rediriger la sortie vers un fichier texte pour une analyse plus approfondie. Je sais que c'est difficile lorsque vous utilisez CGI ...

Source

2012-05-25 13:54:39

cela affichera tous les modules dans le code de base comme étant utilisés/nécessaires , car il existe d'anciennes versions de l'application qui ont été réécrites (copier/coller puis réécrire). Je connais quelques points d'entrée pour l'application, peut-être si je construis un graphique pour ces dépendances et que j'extrais tous les fichiers qui sont liés aux points d'entrée ..... –

Ahh. Vous avez donc 12000 fichiers source, mais vous ne savez pas lesquels sont ou ne sont pas en cours d'exécution? –

Vous devriez être en mesure de déterminer vos points d'entrée à partir des journaux de votre serveur Web. Vous pourriez alors envisager d'écrire une courte araignée pour lire chaque fichier dans la liste, et rechercher les instructions use et require. Enregistrer chaque fichier nouvellement découvert dans un tableau de bord ou un graphique, et le mettre sur la liste, et continuer jusqu'à ce que la liste est vide. –

En supposant que les horodateurs concernés sont activés, vous pouvez vérifier les temps d'accès aux différents fichiers de script - qui devrait exclure tous les fichiers de script de haut niveau qui ne sont pas utilisés.

Cela peut valoir la peine d'ajouter de l'instrumentation à CGI.pm pour enregistrer le nom de script actuel ($ 0) pour voir ce qui se passe.

Source

2012-05-25 15:31:53

merci de votre réponse - il vaut la peine d'enquêter - en particulier pour les ressources non perl comme les images –

Nettoyage énorme Perl Codebase

Répondre

Questions connexes