重构

在已发表的文献中首次使用“重构”一词是在 1990 年 9 月William Opdyke和Ralph Johnson的一篇文章中。 格里斯沃尔德博士 论文，Opdyke 博士 1992年发表的论文也使用了这个术语。

重构活动有两大类好处：

可维护性。更容易修复错误，因为源代码易于阅读并且其作者的意图易于掌握。这可以通过将大型单一例程减少为一组单独的简洁、命名良好、单一用途的方法来实现。可以通过将方法移至更合适的类或删除误导性注释来实现。

可扩展性。如果应用程序使用可识别的设计模式，则更容易扩展应用程序的功能，并且它提供了一些以前可能不存在的灵活性。

马丁·福勒在《重构》¹一书的“2.3 何时重构”小节特地提到了重构的时机：

当我谈论重构，常常有人问我应该怎样安排重构时间表。我们是不是应该每两个月就专门安排两个星期来进行重构呢?

几乎任何情况下我都反对专门拨出时间进行重构。在我看来，重构本来就不是一件应该特别拨出时间做的事情，重构应该随时随地进行。你不应该为重构而重构，你之所以重构，是因为你想做别的什么事，而重构可以帮助你把那些事做好。

所以，使用重构的时机有：

1. 重构作为日常编程的一部分。

2. 在添加新功能时进行重构。

3. 在修改Bug时进行重构。

4. 在代码复审时进行重构。

到了最后的交付期限，不进行重构。

• 封装成员变量（英语：Field encapsulation）（Encapsulate Field）：将仅限于本类使用的变量重写成私有（private）成员变量，并提供访问方法（accessor method）。这种重构方式可以将与外部调用者无关的变量隐藏起来，减少代码的耦合性，并减少意外出错的概率。

• 提取方法（Extract Method）：意思是将大段代码中的一部分提取后，构成一个新方法。这种重构可以使整段程序的结构变得更清晰，从而增加可读性。这也对函数（Function）通用。

• 类一般化（英语：Type generalization）（Generalize Type）：将多个类/函数共用的类型抽象出可以公用的基类（base class），然后利用多态性追加每个类/函数需要的特殊函数。这种重构可以让结构更加清晰，同时可以增加代码的可维护性。

• 函数归父（Pull Up）或函数上移：指的是方法从子类移动到父类。

• 函数归子（Push Down）或译函数下移：指的是方法从父类移动到子类。

• 方法更名（英语：Rename_method）（Rename Method）：将方法名称以更好的表达它的用途。

何时不该重构?

有时候你根本不应该重构，例如当你应该重新编写所有代码的时候。有时候既有代码实在太混乱，重构它还不如重新写一个来得简单。

重写（而非重构）的一个清楚讯号就是：现有代码根本不能正常运作。你可能只是试着做点测试，然后就发现代码中满是错误，根本无法稳定运作。记住，重构之前，代码必须起码能够在大部分情况下正常运作。

一个折中办法就是：将“大块头软件”重构为封装良好的小型组件。然后你就可以逐一对组件做出“重构或重写”的决定。对于一个重要的遗留系统，这肯定会是一个很好的方向。

另外，如果项目已近最后期限，你也应该避免重构。我们可以把未完成的重构工作形容为“债务”。很多公司都需要借债来使自己更有效地运转。但是借债就得付利息，过于复杂的代码所造成的维护和扩展的额外成本就是利息。你可以承受一定程度的利息，但如果利息太高你就会被压垮。把债务管理好是很重要的，你应该随时通过重构来偿还一部分债务。

如果项目已经非常接近最后期限，你不应该再分心于重构，因为已经没有时间了。不过多个项目经验显示：重构的确能够提高生产力。如果最后你没有足够时间重构了，这通常就表示你其实早就该进行重构了。

1. 马丁·福勒：《重构：改进现有代码的设计》，Addison-Wesley Professional 1999, ISBN 978-0-201-48567-7

2. https://www.cnblogs.com/wmyskxz/p/10990059.html

3. https://en.wikipedia.org/wiki/Code_refactoring#Benefits

4. https://zh.m.wikipedia.org/wiki/代码重构