第二章内容：为何重构。
重构与性能优化有很多相似之处：两者都需要修改代码，并且两者都不会改变程序的整体功能。不过两者的差别在于其目的：重构是为了让代码“更容易理解，更容易修改”，性能优化是为了让程序运行的更快。
为何重构：
1、改进软件的设计。
2、使软件更容易理解。
3、帮助找到bug。
4、提高编程速度：从长远来看。
何时重构：
有这么一个三次法则：第一次做某事时只管去做，第二次做类似的事情时会产生反感，但是还可以去做，第三次再做类似的事情，你就应该重构。正如老话：事不过三。
1、预备性重构：让添加新功能更容易。
2、帮助理解的重构：使代码更易懂。
3、捡垃圾式重构：清除垃圾代码。
以上三种都是见机行事类型的重构，遇到了顺便去做，或者记下稍后去做。这些应该是我们编程的一部分，让绝大多数的重构在我们的编程中自然而然的做到。剩下的就是：长期重构（有计划的重构） 和复审代码时重构。
何时不该重构：
第一条：我确定以后都不需要修改它，那我就可以不重构它。
第二条：为了API，暂时可以容忍。
第三条：如果重写比重构容易，那就重写吧，因为重构还得先理解整块代码。不过到底是重写还是重构，这实在不好建议，需要你或者你的leader根据自己丰富的经验来决定。
重构的挑战：
1、延缓新功能开发：显而易见。
2、代码所有权：是否有权限修改，是否会对其他人的代码造成较大的影响。
3、分支：在分支上工作越久，集成回主干的难度越大。建议：每天至少向主干提交一次（在我们这里是，每天都要将主干的代码合并到当前分支）。
4、测试：最好有可以自测试的代码。不然就需要我们的开发环境很好的支持自动化重构，或仅仅使用那些一定安全的重构手法。
5、遗留代码：往往很复杂，最关键的是这是别人写的，且没有相关的测试。
6、数据库。