1 何为重构
重构：对软件内部结构的一种调整，目的是在不改变软件可观察行为的前提下，提高其理解性，降低其修改成本。重构是为了让代码更容易理解，更易于修改。
可观察型为：用户侧关心的行为。
如果有人说他们的代码在重构过程中有一两天时间不可用，基本可以确定，他们在做的事不是重构。
两顶帽子：
- 添加新功能，不应该修改既有代码，只管添加新功能。
- 重构，不能添加新功能，只管调整代码结构。
- 微观上来说，重构与添加新功能是互斥的；但是从宏观来看，重构却可以与添加新功能并行。
比如我需要实现一个新功能，但是现有代码结构混乱，这个时候可以先对代码进行重构，然后再添加新功能。
也可以是添加完新功能之后，发现代码逻辑不合理，可以添加新功能完成之后，再进行重构。
或许整个过程只持续了十分钟，但是我要明确我现在是在做重构，还是在添加新功能。
2 为什么重构
重构绝不是包治百病的灵丹妙药，虽然她不是“银弹”，却可以是一把“银钳子”。可以用于以下几个目的：
- 改进软件设计。代码结构的流失有累积效应，越难看出代码所代表的设计意图，就越难保护其设计，于是设计就腐败得越快。经常性得重构有助于代码维持自己该有的形态。
- 使软件更容易理解。除了计算机之外，源码还有其他读者，计算机编译一段代码的成本通常可以忽略不计，但是读者花上两天时间才看明白代码的意图，才更为致命。并不是说我有多么无私，只是大概率这个阅读者还是我自己。
- 帮忙找bug。有些人盯着一大段代码，可以很块的找到bug，这点我确实不太行。但是如果对代码进行重构，可以深入理解代码的所作所为，并把新的理解反映在代码中，搞清楚代码结构的同时，也验证了自己的理解。
- 提高编程速度。需要添加新功能时，内部质量良好的软件可以让我很容易找到在哪里修改，如何修改，如果代码很清晰，引入bug的可能性就会变小，即使引入bug，调试也容易的多。
3 何时重构
三次法则：第一次做某件事，只管去做；第二次做类似的事，会产生反感，但是还是可以去做；第三次再做类似的事，就应该重构。
事不过三，三则重构。
- 预备性重构。重构的最佳时机是在添加新功能之前。在动手写新功能之前，先看看现有代码，此时经常会发现，如果对代码结构做一点微调，新功能可能会容易很多。例如有一个函数已经实现了部分我想要的功能，只是命名或者几个字段有冲突，这个时候如果先对已有函数进行提炼，再写新功能，可能会容易的多。
- 帮助理解的重构。一旦我需要思考“这段代码到底在做什么”，就要自问：能不能重构这段代码，令其一目了然，通过重构，可以把脑子里的理解，转移到代码本身，如果把对代码的理解植入代码中，这份知识会保存得更久。
- 捡垃圾式重构。已经理解代码在做什么，但是发现她做得不够好，例如逻辑不必要得迂回复杂，或者重复代码等。如果每次经过这段代码时，都把她变好一点，极少成多，垃圾总会被清理干净。就像野营者得老话：至少要让营地比你到达时更干净。
- 有计划的重构和见机行事的重构。上面的三种重构，都是见机行事的，并不会专门安排一段时间，这是自然工作流程的一部分，绝大多数重构都在做其他事情的过程中自然发生。优秀的程序员应该知道，添加新功能最快的方法往往是先修改现有的代码，使新功能容易被加入。
- 长期重构。可以让整个团队达成共识，在未来一段时间里，逐步解决这个问题，这经常是一个有效的策略，每当有人靠近“重构区”的代码，就把她朝想要改进的方向推动一点。这个策略的好处在于，每次小改动之后，整个系统仍然照常工作。
- code review时重构。我在一个星期之内能够想出的好点子有限，如果能得到别人的帮助，生活会滋润很多。如果代码的原作者在旁边，review过程中加入重构效果会好很多，因为作者可以提供上下文信息，并且充分认同reviewer提出的建议。
- 何时不应该重构。如果看见一块凌乱的代码，但并不需要修改它，那么我就不需要重构它。另一种重构是如果重写比重构还容易，就别重构了。在决定要重写还是重构的时候，可以先想下，如果自己重写，会怎么做，如果和现有代码差别不大，大可不必进行重写，如果差别很大，那就可以大胆的进行重写。
4 重构的挑战
生活中总是很少有晴空万里的好事，只有充分了解重构会遇到的挑战，这样才能做出有效应对。
- 延缓新功能开发。有时会看到一个（大规模的）重构很有必要进行，而马上要添加的功能非常小，这时我会更愿意把新功能加上，然后再做这次大规模重构。重构的意义不在于把代码库打磨得闪闪发光，而是重构可以让我们更快——更快得添加新功能，更快得修复bug。
- 代码所有权。代码所有权的边界会妨碍重构，因为一旦自作主张的修改，就一定会破坏调用者的程序，特别时对外提供的API。
- 持续集成。重构经常需要对代码库中的很多地方做很小的修改，这样很容易在合并分支时，造成冲突。一个开发了两个星期的分支，要比一个开发了四个星期的分支，合并到master的难度高不止一倍。因此在重构时，要尽可能频繁的集成。
- 测试。不会改变程序可观察的行为，这是重构的一个重要特征。那如果我在重构过程中改变了程序的行为，犯了错误怎么办？关键在于“快速发现错误”，因此想要重构，就得先有可以自测试的代码。自测试的代码不仅使重构成为可能，而且使添加新功能更加安全，因为我可以很快发现并干掉新引入的bug。这也回答了“重构风险太大，可能引入bug”的担忧。
