这个题目貌似很大，有成为标题党人的嫌疑。其实我想说的是一些小事，就是我小时候经常去小渠里抓鱼。而抓鱼的方式也很简单，就是拿砖块，泥巴把小渠的两头堵起来，然后把中间的水舀出去。

软件为什么要重构？那是因为你感觉不够好。之所以感觉不够好，原因可能会很多。我想，最严重的一个可能就是设计混乱。设计混乱牵扯的方面很多，有依赖上的，有调用上的。也有根本实现不了目的，或者很难扩展。有很多人重构时候干脆就是把代码重写一遍，这种方式固然是好，但是成本太高。有时候无法接受重新梳理一遍代码的工作周期。

如何渐进地进行重构不得不摆在我们面前，而我没有珍惜，等............

对于依赖关系错误的重构是最为复杂的。这个复杂表现在必须重新理顺依赖关系，然后得出解决的方案。而代码调用让人头疼的地方，我想主要在于，没有重用和过度重用两种。扩展上的问题需要重新梳理业务规则，才能制定方案。

毛病很多，头疼医头，脚疼医脚，还真是麻烦。其实最根本的方法还在于学会养生，修炼内功。但路总要一条一条走，饭要一口一口吃啊。遇到这么多复杂的问题，还需要化繁为简。这里的化繁为简在我看来和我小时候抓鱼差不多，需要能够对大量的工作进行截断，一个阶段一个阶段地进行重构。这样才能达成渐进的重构目的。

如何进行工作量的切断，方法很多，但是有个根本的思想在于理清依赖。比如，类B调用了类A，那么B就对A产生了依赖。现在需要对A进行调整，那么就有很大可能对B的正常运行产生影响。如何能隔离B和A，这就需要给A定义规范。这也就是对A进行抽象，提炼出接口IA，那么不管你A怎么变，你符合IA接口的话，就可以给B使用。IA就像我抓鱼时候筑的那条小坝，虽然很小，却很能解决问题。

为什么这样可以解决问题？这就在于，任何一个消费者不会需要知道生产者的一切东西。那么只要把消费者需要的东西拿到就可以。MVC，MVP，三层架构都是大坝，是水渠的两边。而大半框架都是进行水平的划分，垂直的划分一般是以业务来划分。所以，如果软件已经实现了水平的划分，重构起来要轻松很多。那样只需要对业务的垂直划分进行逐步的改造。而如果水平划分没有做，那就惨了，理清头绪都不是件容易的事情。

事实上，重构远没有上面描述的那么简单。比如，以前项目中一直使用ExtJS进行界面的开发，现在想减小JS的比重，因此想改用JQuery+HTML+CSS来替换Ext的控件，那改造起来也是很复杂的事情。一次性全部更新的代价很高，出错机会很大，并且不容易形成规范。需要像国家改革一样形成试点，逐步推广。从这里也可以看出，重构不一定是OO的重构，除非你达到了一切皆是OO的境界。