一般在介绍一样新技术之前，我们都要大致讲讲它的历史、主要原理等等。当然，这些东西很枯燥，很容易诱发我们的瞌睡虫。但是不说，又不能让人理解。好在不是太多。
如果您已经了解重构的定义、原理以及如何重构，那么请跳过本小节。好了，书归正传。
返回总目录
视上下文的不同，重构有两种定义：
重构（名词）：对软件内部结构的一种调整，目的是在不改变软件可观察行为的前提下，提高其可理解性，降低其修改成本。
重构（动词）：使用一系列重构的手法，在不改变软件可观察行为的前提下，调整其结构。
1、重构的目的是使软件更容易被理解和修改。
2、重构不会改变软件的可观察的行为——重构之后软件的功能一如以往。
在使用重构技术开发软件时，有两种截然不同的行为：添加新代码，以及重构。这便是“两顶帽子”。
添加新功能时，你不应该修改既有代码，只管添加新功能。通过测试，你可以衡量自己的工作进度。
重构时你就不能再添加新功能，只管改进程序结构，只在绝对必要时才修改测试。
1、重构改进软件设计
2、重构使软件更容易理解
3、重构帮助找到bug
4、重构提高编程速度
这里作者提出：几乎任何情况下，都反对专门拨出时间进行重构。重构应该随时随地进行。你不应该为重构而重构，之所以重构，是因为你想做别的什么事，而重构可以帮你把那些事做好。
三次法则：第一次做某事只管去做；第二次做类似的事，虽然会反感但也可勉强去做；第三次再做类似的事，你就该重构了。
事不过三，三则重构。
1、添加功能时重构
最常见的时机就是给软件添加新特性的时候，可以帮助我理解需要修改的代码。
如果你发现自己需要为程序添加一个特性，而代码结构使你无法很方便地达成目的，那就先重构那个程序，使特性的添加比较容易进行，然后再添加特性。
2、修补错误时重构
调试过程中运用重构，为了让代码更具可读性，可以加深自己的理解，找出bug。
3、复审代码时重构
重构可以帮助我复审别人的代码，还可以帮助代码复审工作得到更具体的结果。
“该怎么对经理说重构的事”？
对于“质量驱动”型的经理：
在复审中使用重构就是一个不错的办法。大量的研究显示，技术复审是减少错误、提高开发速度的一条重要途径。
随便找一本关于复审、审查或者软件开发的书看看，从中找出最新引证，应该可以让大多数经理认识复审的价值。
对于“进度驱动”型的经理：
最好的办法就是不告诉他。经理要我尽快完事，至于怎么完成，那就是我的事了。我认为最快的方式就是重构，所以我就重构喽。
其实，大多数重构都为程序引入了更多的间接层。间接层是一把双刃剑，因为每次一个东西分成两份，就需要多管理一个东西。
间接层也有其存在的价值。
1、允许逻辑共享
比如一个子函数可以在两个不同的地点被调用，或者基类中的某个函数被所有子类所共享。
2、分开解释意图和实现。
你可以选择每个类和函数的名字，这给了你一个解释自己意图的机会。
3、隔离变化。
4、封装条件逻辑。
1、数据库
2、修改接口
对于已经发布的接口（published interface），无法仅仅修改调用者就能安全的修改接口。你必须同时维护新旧两个接口，幸运的是，这并不难，请尽量这么做：让旧接口调用新接口。同时，使用C#中的Obsolete标记旧接口。
不要过早发布接口。请修改你的代码所有权政策，使重构更顺畅。
3、难以通过重构手法完成的设计改动
我们很难将不考虑安全性需求时构造起来的系统重构为具备良好安全性系统。
何时不该重构
1、重新编写所有代码的时候
有时候既有代码太混乱，重构不如重写来的简单。
重写有一个清楚的讯号：现有代码根本能不正常运行，代码里面满是错误，无法稳定运行。
2、项目已近最后期限
重构的确能提高生产力。如果最后没有足够时间，就表示你其实早该重构。
重构肩负一项特殊使命，它与设计彼此互补。
重构可以带来更简单的设计，同时又不损失灵活性，降低了设计过程的难度，减轻了设计的压力。
关于重构，有一个常被提出的问题：它对程序的性能将造成怎样的影响？
重构的第一步，永远都是为即将修改的代码建立一组可靠的测试环境。好的测试，是重构的根本。
重构技术就是以微小的步伐修改程序。如果你犯下错误，很容易便可发现它。
任何一个傻瓜都能写出计算机可以理解的代码。唯有写出人类容易理解的代码，才是优秀的程序员。
代码首先是给人阅读的，其次才是让计算机运行的。
重构的节奏是怎么样的？可以用这样一个循环来表示：
while(重构){ 测试(); 小修改(); }
好吧。理论知识就是这么多。To Be Continued...
相关文章
