Comment refactoriser une grande base de code en désordre?

Question

J'ai un gros gâchis de code. Certes, je l'ai écrit moi - même- il y a un an. Ce n'est pas bien commenté mais c'est pas très compliqué non plus, donc je peux le comprendre, -- tout simplement pas assez bien pour savoir par où commencer pour aussi loin que la refactorisation.

J'ai violé toutes les règles que j'ai lu au cours de la dernière année. Il y a des classes avec de multiples responsabilités, il y a des accès indirects (j'ai oublié le terme - quelque chose comme foo.bar.doSomething()), et comme je l'ai dit il n'est pas bien commenté. En plus de cela, c'est le début d'un jeu, de sorte que le graphique est couplé avec les données, ou les endroits où j'ai essayé de dissocier les graphiques et les données, j'ai fait les données public pour les graphismes pour être en mesure d'accéder aux données dont il a besoin...

C'est un énorme gâchis! Où dois-je commencer? Comment voulez-vous commencer sur quelque chose comme cela?

Ma démarche actuelle est de prendre les variables et commutateur privé et ensuite refactoriser les pièces qui se brisent, mais qui ne semble pas être suffisant. S'il vous plaît suggérer d'autres stratégies pour patauger à travers ce gâchis et de la transformer en quelque chose de propre pour que je puisse continuer là où j'ai laissé!

---

Mise à jour, deux jours plus tard: j'ai été le dessin UML-comme les diagrammes de mes classes, et la capture de certains de la "Low Hanging Fruits" le long du chemin. J'ai même trouvé quelques morceaux de code qui ont été les débuts de nouvelles fonctionnalités, mais comme je suis en train de slim tout en bas, j'ai été en mesure de supprimer les bits et le projet se sentir plus propre. Je vais probablement refactoriser autant que possible avant de gréement mon cas de test (mais seulement les choses qui sont à 100% certain de ne pas l'impact de la fonctionnalité, bien sûr!), de sorte que je n'aurai pas à refactoriser cas de test que j'ai du changer la fonctionnalité. (vous pensez que je suis en train de faire ou serait-il, à votre avis, être plus facile pour moi de le sucer et écrire les tests en premier?)

Merci de voter pour la meilleure réponse afin que je puisse marquer manière assez! N'hésitez pas à ajouter votre propre réponse à la grappe ainsi, il y a encore de la place pour vous! Je vais lui donner un jour ou deux et puis probablement la marque la plus voté réponse acceptée.

Merci à tous ceux qui ont répondu jusqu'à présent!

---

25 juin 2010: j'ai découvert un blog qui répond directement à cette question de quelqu'un qui semble avoir une assez bonne connaissance de la programmation: (ou peut-être pas, si vous lisez son article :) )

À cette fin, je fais quatre choses quand j' besoin de refactoriser le code:

1. Déterminer quel est le but du code est
2. Tirage UML et les diagrammes d'action des classes concernées
3. Magasinez pour le droit des modèles de conception
4. Déterminer le plus clair de noms pour le courant de classes et de méthodes

Answer 1

Choisissez-vous un exemplaire de Martin Fowler Refactoring. Il a quelques bons conseils sur les moyens de briser votre refactoring problème. Environ 75% de la livre est de petit livre de cuisine de style refactoring étapes que vous pouvez faire. Il préconise également des tests unitaires automatisés que vous pouvez exécuter après chaque étape, afin de prouver votre code fonctionne toujours.

Comme pour un endroit pour commencer, je voudrais m'asseoir et d'en tirer une architecture de haut niveau de votre programme. Vous n'avez pas à obtenir la fantaisie avec détail des modèles UML, mais quelques éléments de base d'UML n'est pas une mauvaise idée. Vous avez besoin d'un big picture idée de la façon dont les pièces majeures de l'ajustement ensemble, de sorte que vous pouvez voir où votre découplage va arriver. Juste une page ou deux de base des diagrammes aidera avec l'émotion que vous avez en ce moment.

Sans une sorte de haut niveau de spécification ou de conception, vous venez de prendre le risque de se perdre encore et de se retrouver avec un autre mess difficile à maintenir.

Si vous avez besoin pour commencer à partir de zéro, n'oubliez pas que vous n'avez jamais vraiment commencer à partir de zéro. Vous avez un peu de code et les connaissances que vous avez acquises à partir de votre première fois. Mais parfois, il ne aider à démarrer avec un projet vide et tirer les choses au fur et à mesure, plutôt que de mettre des incendies dans le fouillis d'un code de base. Rappelez-vous juste de ne pas complètement à jeter, les vieux, les utiliser pour de bonnes parties et de les tirer au fur et à mesure.

Answer 2

Ce qui était le plus important pour moi à différentes occasions, c’était les tests unitaires: j’ai passé quelques jours à écrire des tests pour l’ancien code, puis j’étais libre de procéder à une refactorisation en toute confiance. En quoi est-ce exactement une question différente, mais les tests m'ont permis d'apporter des modifications réelles et substantielles au code.

Answer 3

Je vais le deuxième de chacun des recommandations pour Fowler Refactoring, mais dans votre cas particulier, vous voudrez peut-être chercher à Michael Plumes" de Travailler de façon Efficace avec le Code existant, ce qui est vraiment parfait pour votre situation.

Plumes parle de Tests de Caractérisation, qui sont des tests unitaires de ne pas faire valoir connu comportement du système, mais d'explorer et de définir l'existant (pas clair) le comportement, dans le cas où vous avez écrit votre propre code legacy, et les réparations vous-même, cela peut ne pas être si important, mais si votre conception est bâclée, il est tout à fait possible, il y a des parties du code du travail par la "magie" et leur comportement n'est pas clair, même pour vous, dans ce cas, les tests de caractérisation de l'aide.

Une grande partie du livre est la discussion au sujet de trouver (ou créer) des coutures dans votre base de code -- les coutures sont naturels "lignes de faille", si vous voulez, où vous pouvez rompre dans le système existant pour commencer à le tester, et en le tirant vers une meilleure conception. Difficile à expliquer mais bien intéressant à lire.

Il y a une brève étude de cas où la plume précise de certains des concepts du livre, mais il est vraiment bien la peine de la chasse à l'ensemble de la chose. C'est un de mes favoris.

Answer 4

Vous pouvez toujours commencer à partir de "zéro". Cela ne signifie pas que de la ferraille et de commencer à partir de rien, mais essayez de repenser à haut niveau de choses depuis le début, puisque vous semblez avoir appris beaucoup de choses depuis la dernière fois où vous avez travaillé.

Démarrer à partir d'un niveau plus élevé, et comme vous construire l'échafaudage de vos nouvelles et de l'amélioration de la structure, de tirer tout le code que vous pouvez réutiliser, qui sera probablement plus que vous ne le pensez si vous êtes prêt à le lire, et de faire quelques petits changements.

Lorsque vous avez fait les changements, assurez-vous d'être strict avec vous-même en suivant toutes les bonnes pratiques que vous le savez maintenant, parce que vous allez vraiment vous remercier plus tard.

Il peut être étonnamment rafraîchissant pour bien re-faire programme pour faire exactement ce qu'il a fait avant, mais en plus "proprement". ;)

Comme d'autres l'ont mentionné ainsi, l'unité-les tests sont votre meilleur ami! Ils vous aider à vous assurer que votre refactoring œuvres, et si vous êtes à partir de "zéro", c'est le moment idéal pour écrire.

Answer 5

Juste un supplément de refactoring est plus important que vous ne le pensez: nommer les choses correctement!

Il en va ainsi pour tout nom de variable et le nom de la méthode. Si le nom ne reflète pas exactement ce que la chose est utilisé, alors le renommer en quelque chose de plus précis. Cela peut nécessiter plusieurs itérations. Si vous ne trouvez pas un court, et tout à fait juste de nom, cet élément ne trop et vous avez un excellent candidat pour un extrait de code qui doit être fractionnée. Les noms indiquent clairement où les coupes doivent être faites.

Aussi, le document de votre stuff. Chaque fois que la réponse à POURQUOI? n'est pas clairement communiqué par la réponse à COMMENT? (étant le code), vous devrez ajouter un peu de documentation. La capture des décisions de conception est probablement la tâche la plus importante, car il est très difficile de le faire dans le code.