重构-改善既有代码的设计
--摘录
1.1 何谓重构
重构不只是整理代码，它提供了一种更高效且受控的代码整理技术。运用重构技术后，我发现自己对代码的整理比以前更有效率。
重构的目的是使软件更容易被理解和修改。
使用重构技术开发软件时，你把自己的赶时间分配给两种不同的行为：添加新功能，以及重构（两顶帽子）。添加新功能时，你不应该修改既有代码，只管添加新功能。重构时，你就不能再添加功能，只管改进程序结构。
软件开发过程中，你可能会发现自己经常变换帽子。首先你会尝试添加新功能，然后会意识到：如果把程序结构改一下，功能的添加会容易得多。于是你换一顶帽子，做一会儿重构工作。程序结构调整好后，你又换上原先的帽子，继续添加新功能。新功能正常工作
后，你又发现自己的编码造成程序难以理解，于是又换上重构帽子……整个过程或许只花十分钟，但无论何时你都应该清楚自己戴的是哪一顶帽子。
1.2 为何重构
a.重构改进软件设计
如果没有重构，程序的设计会逐渐腐败变质。当人们只为短期目的，或是在完全理解整体设计之前，就贸然修改代码，程序将逐渐失去自己的结构，程序员愈来愈难通过阅读源码而理解原来的设计。重构很像在整理代码，你所做的就是让所有东西回到应处的位置上
。代码结构的流失是累积性的。愈难看出代码所代表的设计意图，就愈难保护其中设计，于是该设计就腐败得愈快。经常性的重构可以帮助代码自己有的形态。
完成同样一件事，设计不良的程序往往需要更多代码，这常常是因为代码在不同的地方使用完全相同的语句做同样的事。因此改进设计的一个重要方向就是消除重复代码。这个动作的重要性在于方便未来的修改。代码量减少并不会使系统运行更快，因为这对程序的
运行轨迹几乎没有任何明显影响。然而代码量减少将使未来可能的程序修改动作容易得多。代码愈多，正确的修改就愈困难，因为有更多代码需要理解。你在这儿做了点修改，系统却不如预期那样工作，是因为你没有修改另一处——那儿的代码做着几乎完全一样的事情
，只是所处环境略有不同。如果消除重复代码，你就可以确定所有事物和行为在代码中只表述一次，这正是优秀设计的根本。
b.重构使软件更容易理解
所谓程序设计，很大程度上就是与计算机交谈：你编写代码告诉计算机做什么事，它的响应则是精确按照你的指示行动。你得及时填补“想要它做什么”和“告诉它做什么”之间的缝隙。这种编程模式的核心就是“准确说出我所要的”。除了计算机外，你的源码还
有其他读者：几个月后可能会有另一位程序员尝试读懂你的代码并做一些修改。我们很容易忘记这第二位读者，但他才是最重要的。计算机是否多花了几个小时来编译，又有什么关系呢？如果一个程序员花费一周时间来修改某段代码，那才要命呢——如果他理解了你的
代码，这个修改原本只需一小时。
问题在于，当你努力让程序运转的时候，不会想到未来出现的那个开发者。是的，我们应该改变一下开发节奏，对代码做适当修改，让代码变得更易理解。重构可以帮助我们让代码更易读。一开始进行重构时，你的代码可以正常运行，但结构不够理想。在重构上花
一点点时间，就可以让代码更好地表达自己的用途。这种编程模式的核心就是“准确说出我所要的”。
关于这一点，我没必要表现得如此无私。很多时候那个未来的开发者就是我自己。此时重构就显得尤其重要了。我是个很懒惰的程序员，我的懒惰表现形式之一就是：总是记不住自己写过的代码。事实上，对于任何能够立刻查阅的东西，我都故意不去记它，因为我
怕把自己的脑袋塞爆。我总是尽量把该记住的东西写进程序时，这样我就不必记住它了。
这种可理解性还有另一方面的作用。我利用重构来协助我理解不熟悉的代码。每当看到不熟悉的代码，我必须试着理解其用途。我会真正动手修改代码，让它更好地反映出我的理解，然后重新执行，看它是否仍然正常动作，以此检验我的理解是否正确。
一开始我所做的重构都像这样停留在细枝末节上。随着代码渐趋简洁，我发现自己可以看到一些以前看不到的设计层面的东西。研究代码时我发现，重构把我带到更高的理解层次上。
c.重构帮助找到bug
Kent Beck经常形容自己的一句话：“我不是个伟大的程序员，我只是个有着一些优秀习惯的好程序员。”重构能够帮助我更有效地写出强健的代码。
d.重构提高编程速度
终于，前面的一切都归结到了这最后一点：重构帮助你更快速地开发程序。
听起来有点违反直觉。当我谈到重构，人们很容易看出它能够提高质量。改善设计、提升可读性、减少错误，这些都是提高质量。但这难道不会降低开发速度吗？
我绝对相信：良好的设计是快速开发的根本——事实上，拥有良好设计才可能做到快速开发。如果没有良好设计，或许某一段时间内你的进展迅速，但恶劣的设计很快就让你的速度慢下来。你会把时间花在调试上面，无法添加新功能。修改愈来愈长，因为你必须花
愈来愈多的时间去理解系统、寻找重复代码。随着你给最初程序打上一个又一个的补丁，新特性需要更多代码才能实现。真是个恶性循环。
良好设计是维持软件开发速度的根本。重构可以帮助你更快速地开发软件，因为它阻止系统腐败变质，它甚至还可以提高设计质量。
1.3 何时重构
当我谈论重构时，常常有人问我应该怎样安排重构时间表。我们是不是应该每两个月就专门安排两个星期来进行重构呢？
几乎任何情况下我都反对专门拨出时间进行重构。在我看来，重构本来就不是一件应该特别拨出时间做的事情，重构应该随时随地进行。你不应该为重构而重构，你之所以重构，是因为你想做别的什么事，而重构可以帮助你把那些事做好。
三次法则
Don Roberts给了我一条准则：第一次做某件事时只管去做；第二次做类似的事会产生反感，但无论如何还是可以去做；第三次再做类似的事，你就应该重构。即事不过三，三则重构。
a.添加功能时重构
最常见的重构时机就是我想给软件添加新特性的时候。此时，重构的直接原因往往是为了帮助我理解需要修改的代码——这些代码可能是别人写的，也可能是我自己写的。无论何时，只要我想理解代码所做的事，我就会问自己：是否能对这段代码进行重构，使我能
更快地理解它。然后我就会重构。之所以这么做，部分原因是为了让我下次再看这段代码时容易理解，但最主要的原因是：如果在前进过程中把代码结构理清，我就可以从中理解更多东西。
在这里，重构的另一个原动力是：代码的设计无法帮助我轻松添加我所需要的特性。我看着设计，然后对自己说：“如果用某种方式来设计，添加特性会简单得多。”这种情况下我不会因为自己过去的错误而懊恼——我用重构来弥补它。之所以这么做，部分原因是
为了让未来增加新特性时能够更轻松一些，但最主要的原因还是：我发现这是最快捷的途径。重构是一个快速流畅的过程，一旦完成重构，新特性的添加就会更快速、更流畅。
b.修补错误时重构
调试过程中运用重构，多半是为了让代码更具可读性。当我看着代码并努力理解它的时候，我用重构帮助加深自己的理解。我发现以这处程序来处理代码，常常能够帮助我找出bug。你可以这么想：如果收到一份错误报告，这就是需要重构的信号，因为显然代码还不
够清晰——没有清晰到让你能一眼看出bug。
c.复审代码时重构
最好是一个复审者搭配一个原作者，共同处理这些代码。复审者提出修改建议，然后两人共同判断这些修改是否能够通过重构轻松实现。
为什么重构有用？
对于今天的工作，我了解得很充分；对于明天的工作，我了解得不够充分。但如果我纯粹只是为今天工作，明天我将完全无法工作。
重构是一条摆脱困境的道路。如果你发现昨天的决定已经不适合今天的情况，放心改变这个决定就是，然后你就可以完成今天的工作了。明天，回头看今天的理解也许觉得很幼稚，那时你还可以改变你的理解。
是什么让程序如此难以相与?眼下我能想起下述四个原因，它们是：
1）难以阅读的程序，难以修改；
2）逻辑重复的程序，难以修改；
3）添加新行为时需要修改已有代码的程序，难以修改；
4）带复杂条件逻辑的程序，难以修改。
因此，我们希望程序：（1）容易阅读；（2）所有逻辑都只在唯一地点指定；（3）新的改动不会危及现有行为；（4）尽可能简单表达条件逻辑。
重构是这样一个过程：它在一个目前可运行的程序上进行，在不改变程序行为的前提下使其具备上述美好性质，使我们能够保持高速开发，从而增加程序的价值。
1.4 何时不该重构
重写（而非重构）的一个清楚讯号就是：现有代码根本不能正常动作。你可能只是试着做点测试，然后就发现代码中满是错误，根本无法稳定运作。记住，重构之前，代码必须起码能够在大部分情况下正常运作。
另外，如果项目已近最后期限，你也应该避免重构。
重构与设计
重构改变了预先设计的角色。如果没有重构，你就必须保证预先做出的设计正确无误，这个压力太大了。这意味如果将来需要对原始设计做任何修改，代价都将非常高昂。因此你需要把更多时间和精力放在预先设计上，以避免日后修改。
如果你选择重构，问题的重点就转变了。你仍然做预先设计，但是不必一定找出正确的解决方案。此刻的你只需要得到一个足够合理的解决方案就够了。你很肯定地知道，在实现这个初始解决方案的时候，你对问题的理解也会逐渐加深，你可能会察觉最佳解决方案和你当初设想的有些不同。只要有重构这把利器在手，就不成问题，因为重构让日后的修改成本不再高昂。
重构可以带来更简单的设计，同时又不损失灵活性，这也降低了设计过程的难度，减轻了设计压力。一旦对重构带来的简单性有更多感受，你甚至可以不必再预先思考前述所谓的灵活方案——一旦需要它，你总有足够的信心去重构。