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