何时去重构
在前一篇文章中，记录了为什么要去重构，在这篇文章中，我们将会聚焦于何时去重构。
在阐述何时去重构时，先了解三次法则
第一次做某事时只管去做；
第二次做类似的事时，会产生反感，但无论如何还是可以去做；
第三次做相同的事时，你就应该重构
预备性重构
最佳的重构时机是在添加新功能之前。
在添加新功能之前，先检查现有的代码库，通常可以发现其中已经有类似功能的方法。可以对这些方法进行微调，避免出现重复代码。
如果不进行重构，最简单的方式就是复制一份代码，并进行一些微调，例如调整参数或逻辑。这样会导致重复的代码，当需要修改方法时，就必须在两个地方进行修改。甚至在需要新方法时，又会复制一份代码并进行微调。这样反复之后，代码将变得臃肿不堪。
因此，当添加新功能时，如果已有代码库中已经有类似功能的方法，就可以通过函数参数化进行重构。这样一来，只需调用该方法并传入所需的参数即可。
合并重复的代码也会使修复 bug 更加容易。只需在一个地方进行调整，就可以修复相关的 bug，而不必在代码库的各个角落查找重复代码并逐一修复。
帮助理解代码的功能
在修改一段代码之前，我们首先需要弄懂这段代码在做什么。在思考代码是在做什么的过程中，询问自己能不能去重构这段代码，使得它更加容易理解，一目了然。
比如一个糟糕的函数命名，或者一段结构糟糕的逻辑判断都会提醒我们去重构它。
在阅读代码的过程中，我们会形成自己的理解，但这种理解往往不能长时间存于脑中。我们通过重构将自己的理解注入代码中，这样我们的理解就随着代码一起被保存下来了，这样后来的人就可以通过阅读代码获得其中的理解了。并且代码能否正常运行也会验证我们的理解是否正确。
在一次次小的重构之后，代码的逻辑就会逐渐清晰，我们对于代码的理解也会逐渐加深。这时我们就能从更高的角度去理解代码，从而发现隐藏在代码之后的设计问题。如果只是阅读，而没有亲手去重构代码，那就无法获得深入的理解，从而体会到代码背后的设计思路。
在厘清藤蔓和杂枝之后，我们才能看到树干生长的情况。
捡垃圾式重构
在我们理解了代码是在做什么之后， 可能会发现它做的不够好。例如一段设计不合理的逻辑判断语句，两个函数的功能几乎相同，等等。
如果当前手上又着更重要的任务，无法分心太多，而重构有需要花费一定的精力，那么就用便利贴记录下需要重构的地方，在完成任务后重构。如果不需太多的精力，那么就随手将它重构掉。就像看到地上的废纸，随手捡起扔进垃圾桶一样。
Code review 时重构代码
有些公司会代码合并前进行 code review。code review 可以改善开发情况，帮助知识在开发团队中传播，让更多的人了解到代码库中的更多部分。
在 code review 时， 如果采用 Pull Request 方式，由于代码作者不在身边，重构的效果可能并不好。作者可以提供更多的上下文，这对于重构有着积极的作用。在这种情况下，结对编程是最优的选择，在编码的过程中，不断的进行 code review。
何时不要去重构
- 如果代码不需要被修改，那么它就不需要被重构
- 如果丑陋的代码隐藏在 API 下，不需要直接接触，那么就不需要被重构
- 如果一段代码，重写的难度低于重构，那么就去重写，而不是重构