《重构》一书写的非常好，让我大大开阔了思路，认识到对代码的修正是一个可量化、可反复的过程，软件业中最缺乏的好像就是可量化和可反复的过程。

　　但是和大多数引见方法论的书类似，这本书并未对重构的适用范围进行探讨，更没有对理想中软件编码任务中重构的作用和地位做出评价。当然也许这两个问题太过广泛，不容易下一个定论。这篇文章希望能对重构适用的范围和重构在软件开发过程中的位置进行一番探讨，权作抛砖引玉。

　　以下是对重构的受限范围作的一个思考：

　　1.对局部代码的重构与对设计的重构是两个完全不同的领域。虽然大规模的对代码进行重构，也会影响到设计，但是这都是间接的影响。直接针对设计的重构包括重构API契约、领域模型、数据库Schema等“不破不立”的系统关键部分。关于如何对设计进行重构，目前还没有较好的处理方案。

　　推论1：不能把针对局部代码的重构与针对设计的重构混为一谈，尤其留意不能同时进行这两件任务，否则软件开发可能会迅速地失控。

　　2.程序正式发布之前的重构环境与程序发布之后的重构环境完全不同，发布之前，基本上所有东西都可以重构，宏观的包括总体结构、界面、服务层API、数据库Schema，微观的包括一些局部代码的改良等等。但是程序作为产品正式提供应用户后，界面与数据库重构的难度立刻上升。很多时候出于一些非技术缘由，这两种重构基本不可能进行。例如用户不希望界面有任何的变动，除非界面本身曾经不能满足他的需求。数据库重构会形成历史数据与新数据库Schema的不分歧，而迁移数据的风险，通常用户都不情愿接受。

　　推论2：产品发布之后，对界面和数据库Schema（包括实体）的重构非常困难。

　　3.依据经验，如果试图用重构代替事先设计，会导致重构的代价与时间成比例（甚至是指数）上升，而且通常这时进行重构的代价，比简单修正Bug的代价更大。对于重构与设计的关系，一种更优的想法如下：在编写代码之前，合理的尝试做出一个好的设计，然后在编码过程中使用重构来处理余下的设计错误。这里的关键是分配设计与重构的时间比例，以达到最大的投入／产出平衡。

　　推论3：重构对事后设计是一个补充，而不是替代。

　　4.何时停止重构并没有一个量化的标准，依据边际价值递减规律，无休止的重构会使成本上升。

　　推论4：当“编程帽子”可以很容易地戴在头上时，就没有必要继续重构了。如果你仍然看不到如何带上编程这顶帽子，那么就继续重构。

　　以下是对适于重构的情况做的一个简单总结：

　　1.改善API内部的设计。

　　API发布后，通常很难对其签名进行重构，此时可以使用重构来改善其内部设计。

　　2.代码复核时，改善局部代码的质量。

　　找到局部代码的坏味道后，可以使用重构对其进行局部的修正。

　　3.添加新功用之前，整理旧的代码。

　　添加新的功用，如果需求复用以前的一些函数或代码，可以先使用重构使原来的函数或代码更适于复用，然后再编写新的代码。

　　4.设计遇到困难时，可以考虑使用重型重构来改良以往的设计，然后再添加新的设计。重型重构包括界面重构、API重构、领域模型重构、数据库Schema重构，重型重构是有破坏性的，尤其破坏了系统内部和外部的延续性，这与普通的局部重构截然不同，因此使用的时候要格外小心。