重构的定义

我总是对定义一个东西持怀疑态度，因为每个人都有他自己对某东西的一个定义。但是当你写一本书的时候就可以选择一个自己的定义。在这种情况下我 使我的定义基于Ralph Johnson小组的工作。


首先要阐明的是关于重构这个词依赖于上下文有两种定义。你可能会觉得这很烦（我也确实这么认为），但是这也恰恰是另一个运用自然语言我们必须要面对的现实的一个生动的例子。


第一个定义式名词形式的。
重构： 在让软件更容易理解更方便的修改，并且不会改变其可见行为的情况下的对软件内部结构的改变。


你可以在旁边的列表里边找到一些例子，比如Extract Method和Pull Up Field。因此一次重构通常是对软件的一个小的改动，尽管有时候一次会包括了其它的重构。比如说，Extract Class 通常都会包含Move Method和Move Field。


另一个定义式动词形式的。
重构：在不改变软件的外部可见行为的前提下，通过运用一系列的重构手法来对软件内部结构进行重组。


你可能花了几个小时重构，在这期间你可能运用了很多你个人想到的重构手法。


我曾经被问过这样的问题，“重构是不是就只是让代码更整洁？” 在某种情况下答案是肯定的，但是我觉得重构会更深入一点，因为它提供给我们一个更加高效的技术和可控的习惯来让代码更整洁。自从我开始用重构，我注意到我整洁代码变得更高效多了。这是因为我知道我该用哪种重构手法，我知道怎么有一个更好的使用它们的习惯来让将bug出现的概率降到最小，并且我会再每一个可能的时候运行测试。


我应该在我的定义中扩展出一些关键点。首先，重构的目的是让软件更加易于理解和修改。你可以给软件做很多修改却不改变或者极少的修改其外部可见行为。只有对软件更加容易理解的改变才是重构。一个好的对比就是性能优化。和重构一样，性能优化通常不会改变一个组件的行为（速度除外）；它只是改造了其内部结构。然而，目的是不同的。性能优化通常会让代码变得难以理解，但是你需要这么做来达到性能上的要求。


第二点我想强调的是重构不改变软件的外部可见行为。软件还是向外提供和之前一样的功能。任何它的用户，不管是最终用户还是另外的程序员，都说不出发生了什么改变。


两顶帽子


这第二点引出了Kent Beck关于两顶帽子的比喻。当你运用重构开发的时候，你会把你的时间分成两个不同的活动：添加新功能和重构。当你在添加新功能的时候，你不应该修改已有代码；你只是添加新的功能。这样你可以通过添加测试然后让测试通过来量化你的进度。当你重构的时候，你注意一点不添加任何新功能，只是重构代码。你不会添加任何测试（除非你发现有一种情况之前漏掉了）；你只需要重组代码。你不会添加任何测试（除非你发现有一种情况之前漏掉了）；你只有在绝对的需要去应付一个接口的变化的时候才会改测试。

当你在开发软件的时候，你可能会发现你在这两顶帽子之间切换的很频繁。当你要开始增加一个新功能的时候，你意识到如果把代码改成另外一个结构会让添加新功能呢变得简单很多。因此你会切换帽子到重构一段时间。当代码结构变得好些的时候，你会切换帽子回来开始添加新的功能。当你添加的新功能可能工作了之后，你会发现你的代码变得丑陋并且难以理解，你将再次切换帽子对代码进行重构。所有这些可能只花了十分钟，但是在这其间你应该总是很清楚的知道当前戴的是哪顶帽子。

原文链接：https://sourcemaking.com/refactoring/defining-refactoring