重构

重构

  所谓重构(refactoring)是这样一个过程：在不改变代码外在行为的前提下，对代码做出修改，以改进程序的内部结构。重构是一种经千锤百炼形成的有条不紊的程序整理方法，可以最大限度地减少整理过程中引入错误的概率。本质上说，重构就是在代码写好之后改进它的设计。

  “在代码写好之后改进它的设计”这种说法有点儿奇怪。在软件开发的大部分历史时期，大部分人相信应该先设计而后编码：首先得有一个良好得设计，然后才能开始编码。但是，随着时间流逝，人们不断修改代码，于是根据原先设计所得的系统，整体结构逐渐衰弱。代码质量慢慢沉沦，编码工作从严谨的工程堕落为胡砍乱劈的随性行为。

  “重构”正好与此相反。哪怕手上有一个糟糕的设计，甚至是一堆混乱的代码，我们也可以借由重构将它加工成设计良好的代码。重构的每个步骤都很简单，甚至显得有些过于简单：只需要把某个字段从一个类移到另一个类，把某些代码从一个函数拉出来构成另一个函数，或是在继承体系中把某些代码推上推下就行了。但是聚沙成塔，这些小小的修改累积起来就可以根本上改善设计质量。这和一般常见的“软件会慢慢腐烂”的观点恰恰相反。

  有了重构以后，工作的平衡点开始发生变化。我发现设计不是在一开始完成的，而是在整个开发过程中逐渐浮现出来。在系统构筑过程中，我学会了如何不断改进设计。这个“构筑 - 设计”的反复互动，可以让一个程序在开发过程中持续保有良好的设计。

重构与设计

基本不可能通过预先设计就建造一个可以应对各种变化的灵活的解决方案。用户的需求是不确定且可能还是不断变化的，软件需求会随着迭代的进行做各种调整。因此，仅仅通过预先做好设计，是很难满足移动开发和敏捷开发需求的了。
一些极限编程的支持者认为可以不做任何设计，只管按照最初想法开始编码，让代码有效运作，然后再将它重构成型，最终获得设计良好的软件。这种做法确实可行，但并不是最有效的途径。事先做好设计可以节省高昂的返工成本。

更有效的做法是依然做预先设计，但不必一定找出正确的解决方案，只需要先设计一个足够合理的解决方案就够了，在实现这个解决方案的时候，对问题的理解也会逐渐加深，可能会察觉最佳解决方案和当初设想的有所不同，再通过重构，使得预先设计方案逐渐演变为最佳的解决方案。

重构与性能
如果做的任何修改都是为了提高性能，通常都会难以维护，影响开发效率。如果最终得到的软件更快了，那么这些损失尚有所值，可惜通常事与愿违，因为性能改善分散到程序各角落，每次改善不过是从程序行为的狭隘角度出发的。
前期开发应当编写良好的程序，不对性能投以特别的关注，直至性能优化阶段，再按照某个特定程序对性能进行优化。

重构使代码容易理解和修改，从而使得性能优化变得容易

程序耗时的部分往往集中在一小部分代码上，对性能做优化，就是主要对这一部分耗时代码的优化。短期来看，重构可能使软件变慢，但它使优化阶段的软件性能调整更容易，最终得到好的效果。
在性能优化阶段，首先应该用一个度量工具来监控程序的运行，找到程序中哪些地方在大量消耗时间和空间。这样就可以找出性能热点所在的一小段代码。然后集中关注这些性能热点，并使用持续关注法中的优化手段来优化它们。简言之就是：发现热点，去除热点。

通过重构我们能得到什么？

1.重构能够改进软件设计

代码结构的流失是累积性的。越难看出代码的设计意图，就越难保护其中的设计，于是该设计就腐败的越快。而经常性的重构可以帮助代码维持自己的形态和结构。

完成同样一件事，设计不良的程序往往需要更改代码，这通常是因为相同的代码在不同的地方做着同样的事。如果消除重复代码，你就可以确定所有的事物、行为在代码中只表述一次，这正是优秀设计的根本。

2.重构使软件更容易理解

重构会使代码渐趋简洁，越简洁就越容易理解，越容易理解就越容易修改…

3.重构能够找到代码中隐藏的bug

对代码进行重构，可以更深入的理解代码，搞清楚程序的结构，于是bug就被揪出来了。

重构能够帮助程序员更有效的写出更强健的代码。

4.重构提高编程速度

良好的设计是开发的根本，拥有良好的设计才可能做到快速开发。如果没有良好的设计，或许短时间内进展迅速，但是恶劣的设计很快就让你的速度慢下来。你会花费大量的时间进行调试，添加新功能难度越来越高，修改时间越来越长，bug越藏越深，为了解决问题于是一个又一个补丁出现…哦~真是一个恶性循环。

重构可以帮助你更快的开发软件，因为它阻止系统腐败变质，它甚至还可以提高设计质量。