第2章 重构原则
重构：改善既有代码的设计
前面所举的例子应该已经让你对重构有了一个良好的感受。现在，我们应该回头看看重构的关键原则，以及重构时需要考虑的某些问题。
2.1 何谓重构
我总是不太喜欢下定义，因为每个人对每样东西都有自己的定义。但是既然在写书，总得选择自己满意的定义。在重构这个概念上，我的定义以Ralph Johnson团队和其他相关研究成果为基础。
首先要说明的是：视上下文不同，“重构”这个词有两种不同的定义。你可能会觉得这挺烦人的（我就是这么想的），不过处理自然语言本来就是件烦人的事，这只不过是又一个实例而已。
第一个定义是名词形式。
重构（名词）：对软件内部结构的一种调整，目的是在不改变软件可观察行为的前提下，提高其可理解性，降低其修改成本。
你可以在后续章节中找到许多重构范例，诸如Extract Method(110)和Pull Up Field (320)，等等。一般而言，重构都是对软件的小改动，但重构之中还可以包含另一个重构。例如Extract Class (149)通常包含Move Method(142)和Move Field(146)。
“重构”的另一个用法是动词形式。
重构（动词）：使用一系列重构手法，在不改变软件可观察行为的前提下，调整其结构。
所以，在软件开发过程中，你可能会花上数小时进行重构，其间可能用上数十种重构手法。
曾经有人这样问我：“重构就只是整理代码吗?”从某种角度来说，是的。但我认为重构不止于此，因为它提供了一种更高效且受控的代码整理技术。自从运用重构技术后，我发现自己对代码的整理比以前更有效率。这是因为我知道该使用哪些重构手法，也知道以怎样的方式使用它们才能够将错误减到最少，而且在每一个可能出错的地方我都加以测试。
我的定义还需要往两方面扩展。首先，重构的目的是使软件更容易被理解和修改。你可以在软件内部做很多修改，但必须对软件可观察的外部行为只造成很小变化，或甚至不造成变化。与之形成对比的是性能优化。和重构一样，性能优化通常不会改变组件的行为（除了执行速度），只会改变其内部结构。但是两者出发点不同：性能优化往往使代码较难理解，但为了得到所需的性能你不得不那么做。
我要强调的第二点是：重构不会改变软件可观察的行为——重构之后软件功能一如以往。任何用户，不论最终用户或其他程序员，都不知道已经有东西发生了变化。
两顶帽子
上述第二点引出了Kent Beck的“两顶帽子”比喻。使用重构技术开发软件时，你把自己的时间分配给两种截然不同的行为：添加新功能，以及重构。添加新功能时，你不应该修改既有代码，只管添加新功能。通过测试（并让测试正常运行），你可以衡量自己的工作进度。重构时你就不能再添加功能，只管改进程序结构。此时你不应该添加任何测试（除非发现有先前遗漏的东西），只在绝对必要（用以处理接口变化）时才修改测试。
软件开发过程中，你可能会发现自己经常变换帽子。首先你会尝试添加新功能，然后会意识到：如果把程序结构改一下，功能的添加会容易得多。于是你换一顶帽子，做一会儿重构工作。程序结构调整好后，你又换上原先的帽子，继续添加新功能。新功能正常工作后，你又发现自己的编码造成程序难以理解，于是又换上重构帽子……整个过程或许只花十分钟，但无论何时你都应该清楚自己戴的是哪一顶帽子。