Conseils pour refactoriser une bibliothèque de lignes 20K

Question

J'ai déjà reçu un bounty de 100 points de mario réponse, mais pourriez commencer une seconde de 100 points bounty si je vois de nouvelles bonnes réponses à venir dans. C'est pourquoi je suis à la maintenir ouverte la question et de ne pas choisir une réponse définitive, en dépit de l'octroi de la prime de mario.

Cela peut sembler une question simple (étudier le code et refactoriser) mais j'espère que ceux ayant beaucoup plus d'expérience peut me donner de bons conseils.

La bibliothèque est une source ouverte de 20 000 ligne de la bibliothèque que tout est dans un seul fichier et que je n'ai pas écrit moi-même. Le code est mal écrit et le seul fichier, c'est même un gros problème, car il gèle eclipse pour une demi-minute au moins à chaque fois que je veux faire un changement, qui est l'une des raisons pour lesquelles je pense qu'il vaut la peine de revoir cette librairie dans les petites classes.

Donc, en plus de la lecture du code et essayer de le comprendre, est-il commun (ou pas si commun) conseils lors d'un refactoring d'une bibliothèque de ce type? Que conseillez-vous de faire de ma vie un peu plus facile?

Merci à tous pour vos commentaires.

Answer 1

Quelques principes généraux s'appliquent:

1. Diviser et conquérir. Diviser le fichier en des petits, logique des bibliothèques et de la fonction des groupes. Vous en apprendrez plus sur la bibliothèque de cette façon, et de le rendre plus facile à comprendre et à tester de manière incrémentale.

2. D'éliminer les doubles emplois. Look de répéter les fonctions et les concepts, et de les remplacer par des fonctions de la bibliothèque standard, ou des fonctions centralisées au sein de la bibliothèque.

3. Ajouter de la cohérence. Lisser les paramètres et en les nommant.

4. Ajouter des tests unitaires. C'est la partie la plus importante de refactoring d'une bibliothèque. Utiliser jUnit (ou similaire), et ajouter des tests que vous pouvez utiliser pour vérifier que les fonctions sont à la fois correctes et qu'elles n'ont pas changé.

5. Ajouter docs. Document de votre compréhension de la cohérence, de l'amélioration de la bibliothèque que vous écrivez vos tests.

Answer 2

Si le code est mal écrit, il est probable qu'il a beaucoup de clonage. Trouver et se débarrasser des clones seraient alors susceptibles de le rendre beaucoup plus facile à gérer ainsi que la réduction de sa taille.

Vous pouvez trouver une grande variété de clone de détecteurs, de ces spécifiquement pour PHP:

• Bergmann PHPCPD
• SourceForge PMD
• Notre CloneDR

classé au moins à la plupart des capacités de l'ordre (à mon humble avis, avec mon fort leur intérêt personnel dans CloneDR) en termes de qualitativement différent de la capacité à détecter des clones intéressants.

Si le code est mal écrit, beaucoup de il serait peut-être morte. Il serait intéressant de savoir quelle partie s'exécute dans la pratique, et qui ne l'est pas. Un outil de couverture de test peuvent vous donner un bon aperçu de la réponse à cette question, même en l'absence de tests (vous simplement exercer votre programme à la main). Ce que l'outil de couverture de test dit exécute, évidemment ce n'est pas morte. Ce n'exécute pas... peut-être la peine d'être approfondie pour voir si vous pouvez le supprimer. Un outil de couverture de test est également utile de vous dire combien de code est exercé par des tests unitaires, comme l'a suggéré une autre réponse. Enfin, un outil de couverture de test peut vous aider à trouver où certaines fonctionnalités sont: exercice de la fonctionnalité de l'extérieur, et quel que soit le code de l'outil de couverture de test est dit est exécutée est sans doute pertinente.

Notre PHP Outil de Couverture de Test peut recueillir de la couverture de test des données.

Answer 3

Si c'est une bibliothèque open source, demander aux développeurs. D'abord il est très probable que quelqu'un a déjà (tentative de) une version restructurée. Et très occasionnellement le gros bouffi version de quelque chose était en fait auto-généré à partir d'un plus version modulaire.

En fait je fais parfois pour une de mes applications, ce qui est strictement pluginized, et permet à un simple cat */*.php > monolithic.php, ce qui facilite la distribution et la manutention. Afin de vous demander si cela pourrait être le cas là.

Si vous avez vraiment envie de le restructurer, puis utilisez la éprouvées élargissement progressif de la structure. Diviser la classe library dans plusieurs fichiers, en séparant la classe d'origine. Diviser chaque ~ 2000 lignes, et le nom de la première partie library0.php:

 class library0 {
     var $var1,$var2,$var3,$var4;
     function method1();
     function method2();
     function method3();
     function method4();
     function method5();

La prochaine partie simple, va à partir de là et titulaire de la prochaine quelques méthodes:

 class library1 extends library0 {
     function method6();
     function method7();
     function method8();
     ...

Le faire jusqu'à ce que vous avez séparé d'eux tous. Appeler le dernier fichier par son nom réel library.php, et class library extends library52 { devrait le faire. C'est tellement ridiculement simpliste, un regex script doit être en mesure de le faire.

Maintenant, évidemment, il n'y a pas de mémoire de l'épargne ici. Et de le diviser comme ça vous achète rien en termes de structuration. Avec 20000 lignes, il est cependant difficile d'obtenir un aperçu rapide et senseful groupement droite la première fois. Donc, commencer avec un arbitraire de la restructuration à la place d'une évidente plan. Mais aller à partir de là, vous pourriez très bien trier et de mettre le moins utile de code dans le dernier fichier, et d'utiliser le plus léger des classes de base à chaque fois qu'ils suffire. Vous aurez besoin d'une dépendance graphique mais pour voir si c'est réalisable, d'autre erreurs peuvent souffler jusqu'à l'exécution.

(Je n'ai pas essayé cette approche avec un gros projet comme ça. Mais arbitrairement quelque chose de fractionnement en trois parties, puis remaniement pour la sensibilité n'a fonctionné. Qu'une seule fois.)

Answer 4

• Je suppose que vous prévoyez de diviser la bibliothèque en classes thématiques pertinentes. Envisagez certainement d' utiliser le chargement automatique . C'est la meilleure chose depuis le pain tranché et rend les interdépendances faciles à gérer.

• Documentez le code en utilisant les commentaires compatibles phpDoc dès le début.

Answer 5

Un bon livre qui répond à votre question avec beaucoup d'exemples et de détails est: Travailler efficacement avec Legacy Code, par Michael Feathers.