CH02_重构的原则（什么是重构、为什么重构、何时重构）

什么是重构

重构（名词）：对软件内部结构的一种调整，目的是在不改变软件可观察行为的前提下，提高其可理解性，降低其修改成本。

重构（动词）：使用一系列重构手法，在不改变软件可观察行为的前提下，调整其结构。

重构的关键在于运用大量微小且保持软件行为的步骤，一步步达成大规模的修改。每个单独的重构要么很小，要么由若干小步骤组合而成。

可观察行为：整体而言，经过重构之后的代码所做的事应该与重构之前大致一样。

重构与性能优化有很多相似之处：两者都需要修改代码，并且两者都不会改变程序的整体功能。两者的差别在于其目的：重构是为了让代码“更容易理解，更易于修改”。这可能使程序运行得更快，也可能使程序运行得更慢。在性能优化时，只关心让程序运行得更快，最终得到的代码有可能更难理解和维护。

两顶帽子

这是一个比喻，使用重构技术开发软件时，我把自己的时间分配给两种截然不同的行为：添加新功能和重构。添加新功能时，我们不应该修改既有代码，只管添加新功能。重构时我们就不饿能添加功能，只管调整代码的结构。

实际开发过程中，我们可能需要经常变换帽子。如果把程序结构改一下，功能的添加会容易得多；新功能添加好了以后发现代码难以理解，则继续重构。

为何重构

我们之所以重构，因为它能让我们更快——添加功能更快，修复bug更快。

重构改进软件的设计

没有重构，程序的内部设计（架构）会逐渐腐败变质。当人们只为短期目的而修改代码时，他们经常没有完全理解架构的整体设计，于是代码逐渐失去了自己的结构。程序员越来越难通过阅读源码来理解原来的设计。

经常性的重构有助于代码维持自己该有的形态。

重构使软件更容易理解

写让计算机理解的代码很容易，只要能编译通过并运行；但写出让别人能理解的代码则需要下点功夫了。所以我们写代码要考虑以后那个修改的人，而且那个人很可能是哦我们自己。

开始进行重构前，代码可以正常运行，但结构不够理想。在重构上花一点点时间，就可以让代码更好地表达自己的意图。

重构帮助找到Bug

对代码进行重构，就可以深入理解代码的所作所为，并立即把新的理解反映在代码当中。搞清楚程序结构的同时，也验证了所做的一些假设，更容易将Bug找出来。重构能够帮助我们更有效地写出健壮的代码。

重构提高编程速度

设计耐久性假说：通过投入精力改善内部设计，我们增加了软件的耐久性，从而可以更长时间地保持开发的快速。

在这里插入图片描述

行业的陈规认为：良好的设计必须在开始编程之前完成，因为一旦开始编写代码，设计就只会逐渐腐败。重构改变了这个图景。现在我们可以改善已有代码的设计，因此我们可以先做一个设计，然后不断改善它，哪怕程序本身的功能也在不断发生着变化。由于预先做出良好的设计非常困难，想要既体面又快速地开发功能，重构必不可少。

何时重构

三次法则

第一次做某件事时只管去做
第二次做类似的事会产生反感，但无论如何还是可以去做
第三次再做类似的事，你就应该重构。

预备性重构：让添加新功能更容易

重构的最佳时机就在添加新功能之前。例如有个函数提供了我们需要的大部分功能，只是有几个变量跟我们需要的冲突，通常我们的做法使把这个函数复制过来，修改几个值。这样做会导致重复代码（将来有可能需要修改两处）。使用函数参数化（310）进行重构后，只需要调用这个函数，传入需要的参数。

修复bug时的情况也是一样。在寻找问题根因时，可能会发现：如果把3段一模一样且都会导致错误的代码合并到一处，问题修复起来会容易得多。

帮助理解的重构：使代码更易懂

重构带来的帮助不仅发生在将来——常常是立竿见影。先在一些小细节上使用重构来帮助理解，给一两个变量改名，让它们更清楚地表达意图，以方便理解，或是将一个长函数拆成几个小函数。当代码变得更清晰一些时就会看见之前看不见的设计问题。

捡垃圾式重构

帮助理解的重构还有一个变体：已经理解代码在做什么，但发现它做得不好，例如逻辑不必要地迂回复杂，或者两个函数几乎完全相同，可以用一个参数化的函数取而代之。有两种处理方式：如果垃圾很容易重构，马上重构它；如果重构需要花一些精力，记录下来，完成当下的任务再回来重构它。

有计划的重构

一般项目计划上没有专门留给重构的时间，绝大多数重构都在做其他事的过程中自然发生。如果团队过去忽视了重构，那么常常会需要专门花一些时间来优化代码库，以便更容易添加新功能。

长久以来，人们认为编写软件是一个累加的过程：要添加新功能，我们就应该增加新代码。但优秀的程序员知道，添加新功能最快的方法往往是先修改现有的代码，使新功能容易被加入。所以，软件永远不应该被视为“完成”。每当需要新能力时，软件就应该做出相应的改变。越是在已有代码中，这样的改变就越显重要。

何时不应该重构

如果有一块凌乱的代码，但并不需要修改它，那么就不需要重构它。如果丑陋的代码能被隐藏在一个API之下，暂时容忍它继续保持丑陋。只有当需要理解其工作原理时，对其进行重构才有价值。

另一种情况是，如果重写比重构还容易，就别重构了。

重构的挑战

延缓新功能开发

很多人认为，花在重构的时间是在拖慢新功能的开发进度。“重构会拖慢进度”这种看法仍然很普遍，这可能是导致人们没有充分重构的最大阻力所在。

重构的唯一目的就是让我们开发更快，用更少的工作量创造更大的价值。

有一种情况确实需要权衡取舍：有时会看到一个（大规模的）重构很有必要进行，而马上要添加的功能非常小，这时可以先把新功能加上，然后再做这次大规模重构。

测试

如果开发环境（开发工具）能很好的支持自动化重构，则可以信任这些重构；如果不能最好有完备的测试套件（测试环境、测试代码、单元测试等）。

遗留代码

遗留代码往往很复杂，可能也没有充足的测试，关键还是别人写的。如果不幸遇到，没有什么好办法：没测试就加测试、随时重构相关的代码（不建议尝试一鼓作气把复杂而混乱的遗留代码重构成漂亮的代码）。

重构、架构和YAGNI

YAGNI：“你不需要它（you are`t going to need it）”。YAGNI并不是“不做架构性思考”的意思，不过确实有人以这种欠考虑的方式做事。

重构对架构最大的影响在于，通过重构，我们能得到一个设计良好的代码库，使其能够优雅地应对不断变化的需求。“在编码之前先完成架构”这种做法最大的问题在于，它假设了软件的需求可以预先充分理解。但经验显示，这个假设很多时候甚至可以说大多数时候是不切实际的。只有真正使用了软件、看到了软件对工作的影响，人们才会想明白自己到底需要什么。