您如何重构大型凌乱的代码库? [英] How do you refactor a large messy codebase?

问题描述

我的代码很乱.不可否认，我是一年前写的.它的注释不充分，但也不是很复杂，所以我可以理解它-只是不足以知道从何处开始进行重构.

I have a big mess of code. Admittedly, I wrote it myself - a year ago. It's not well commented but it's not very complicated either, so I can understand it -- just not well enough to know where to start as far as refactoring it.

我违反了过去一年中所阅读的每条规则.有些班级承担多重责任，有间接访问权(我忘记了这个术语-类似于foo.bar.doSomething()之类的东西)，就像我说的那样，它没有被很好地注释.最重要的是，这是游戏的开始，因此图形与数据结合在一起，或者我尝试将图形与数据脱钩的地方，我制作了数据public以便能够访问图形它需要的数据...

I violated every rule that I have read about over the past year. There are classes with multiple responsibilities, there are indirect accesses (I forget the term - something like foo.bar.doSomething()), and like I said it is not well commented. On top of that, it's the beginnings of a game, so the graphics is coupled with the data, or the places where I tried to decouple graphics and data, I made the data public in order for the graphics to be able to access the data it needs...

这真是一团糟！我从哪里开始?您将如何开始这样的事情?

我当前的方法是获取变量并将其切换为私有变量，然后重构那些破坏的部分，但这似乎还不够.请提出其他策略，以渡过这个烂摊子并将其转变为干净的东西，以便我可以继续上次离开的地方！

My current approach is to take variables and switch them to private and then refactor the pieces that break, but that doesn't seem to be enough. Please suggest other strategies for wading through this mess and turning it into something clean so that I can continue where I left off!

两天后更新::我一直在绘制类的UML形图，并在此过程中捕捉到一些悬空果".我什至已经找到了一些新功能的开始的代码，但是当我尝试精简所有内容时，我已经能够删除这些位并使项目变得更加整洁.在安装测试用例之前，我可能会尽可能地进行重构(但是，当然只有100％的东西不会影响功能！)，这样我就不必重构测试用例了.更改功能. (您认为我做得对吗，或者您认为我会更容易吸纳它并首先编写测试?)

Update two days later: I have been drawing out UML-like diagrams of my classes, and catching some of the "Low Hanging Fruit" along the way. I've even found some bits of code that were the beginnings of new features, but as I'm trying to slim everything down, I've been able to delete those bits and make the project feel cleaner. I'm probably going to refactor as much as possible before rigging my test cases (but only the things that are 100% certain not to impact the functionality, of course!), so that I won't have to refactor test cases as I change functionality. (do you think I'm doing it right or would it, in your opinion, be easier for me to suck it up and write the tests first?)

请对最佳答案进行投票，以便我可以公平地标记它！也可以随意添加您自己的答案，仍然有空间供您使用！我会再等一天，然后可能将投票最高的答案标记为已接受.

Please vote for the best answer so that I can mark it fairly! Feel free to add your own answer to the bunch as well, there's still room for you! I'll give it another day or so and then probably mark the highest-voted answer as accepted.

感谢迄今已做出回应的每个人！

Thanks to everyone who has responded so far!

2010年6月25日:我发现一篇博文，该博文直接回答了一个似乎非常了解编程的人的问题:(或者，如果您读过他的文章，也许不是):

June 25, 2010: I discovered a blog post which directly answers this question from someone who seems to have a pretty good grasp of programming: (or maybe not, if you read his article :) )

为此，当我做四件事时 需要重构代码:

To that end, I do four things when I need to refactor code:

1. 确定代码的目的是什么
2. 绘制所涉及类的UML和动作图
3. 货比三家以寻求正确的设计模式
4. 确定当前类和方法的更清晰的名称

1. Determine what the purpose of the code was
2. Draw UML and action diagrams of the classes involved
3. Shop around for the right design patterns
4. Determine clearer names for the current classes and methods

推荐答案

自行挑选Martin Fowler的重构.它对解决重构问题的方法提供了一些很好的建议.本书中约有75％是您可以完成的食谱式重构步骤.它还提倡自动单元测试，您可以在每个步骤之后运行该单元测试，以证明您的代码仍然有效.

Pick yourself up a copy of Martin Fowler's Refactoring. It has some good advice on ways to break down your refactoring problem. About 75% of the book is little cookbook-style refactoring steps you can do. It also advocates automated unit tests that you can run after each step to prove your code still works.

作为起点，我会坐下来，为您的程序画一个高级架构.您不必看详细的UML模型，但是一些基本的UML并不是一个坏主意.您需要大致了解主要部分如何组合在一起，以便可以直观地看到去耦将在何处发生.只需一到两个基本框图中的一两个页面，就可以帮助您解决目前的压倒性感觉.

As for a place to start, I would sit down and draw out a high-level architecture of your program. You don't have to get fancy with detailed UML models, but some basic UML is not a bad idea. You need a big picture idea of how the major pieces fit together so you can visually see where your decoupling is going to happen. Just a page or two of some basic block diagrams will help with the overwhelming feeling you have right now.

如果没有某种高级规格或设计，您将面临再次迷失并最终陷入另一场难以维持的混乱局面的风险.

Without some sort of high level spec or design, you just risk getting lost again and ending up with another unmaintainable mess.

如果您需要从头开始，请记住，您从未真正从头开始.您有一些代码和从第一次获得的知识.但是有时候从一个空白项目开始并随身携带东西确实有帮助，而不是在凌乱的代码库中扑朔迷离.只是要记住不要完全扔掉旧的东西，将其用作好零件并随身携带.

If you need to start from scratch, remember that you never truly start from scratch. You have some code and the knowledge you gained from your first time. But sometimes it does help to start with a blank project and pull things in as you go, rather than put out fires in a messy code base. Just remember not to completely throw out the old, use it for its good parts and pull them in as you go.

这篇关于您如何重构大型凌乱的代码库?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！