代码不可能在第一次就写得完美，这是一个持续修改的过程，那么应该怎么来进行呢？ 以下内容来自《重构-改善既有代码的设计》

是什么

• 好代码的检验标准就是人们是否能轻而易举地修改它。
• 由于预先做出良好的设计非常困难，想要既体面又快速地开发功能，重构必不可少。
• 重构的意义就在于：你永远不必说对不起，只要把出问题的地方修补好就行了。
• 重构过程的精髓所在：小步修改，每次修改后就运行测试。
• 重构的最佳时机就在添加新功能之前。
• 我不专门安排一段时间来重构，而是在添加功能或修复bug的同时顺便重构。
• 与其猜测未来需要哪些灵活性，需要什么机制来提供灵活性，我更愿意只根据当前的需求来构造软件。

做什么

• 数据结构才是一个健壮程序的根基。
• 消除重复。
• 函数是我们将程序拆分成小块的主要方式。
• 根据一个函数的意图（做什么）来对它命名。
• 只要改名能够提升代码的可读性，那就应该毫不犹豫去做。
• 如果某些数据和某些函数总是一起出现，某些数据经常同时变化甚至彼此相依，这就表示你应该将它们分离出去(比如提炼类)。
• 一个好的模块化的设计，"封装"是最关键的特征之一。"封装"意味着每个模块都应该尽可能少了解系统的其他部分。
• 尽量遵循命令与查询分离原则。
• 大部分条件逻辑只用到了基本的条件语句，但如果发现复杂条件逻辑，多态是改善这种情况的有力工具。
• 合理的继承关系是在程序演化的过程中才浮现出来的：我发现了一些共同元素，希望把它们抽取到一处，于是就有了继承关系。

注意什么

• 数据被使用得越广，就越是值得花精力给它一个体面的封装。
• 如果可访问范围变大，重构的难度就会随之增大，这也是说全局数据是大麻烦的原因。
• 将一个值用于多个不同的用途，这就是催生混乱和bug的温床。
• 如果你不知道该做什么，这才是注释的良好运用时机。
• 重构过程的性能问题：大多数情况下可以忽略它，如果有性能损耗，先完成重构，再做性能优化。
• 如果重写比重构还容易，就别重构了。

一直在追问自己要不要总结一篇这样偏理论性的文章。其实大部头的书不太容易静下心来读，那么我就把一些基本的知识晒出来，让看到的人产生思考，然后能去读原书。就算不读这本421页的《重构》也能对重构有一个基本的了解，方便在日后遇到问题时，知道去哪里寻找答案。

原书总结了常用的上百种重构手法，如果真正理解了什么是重构，自己也可以创造一些手法，实际的业务场景才是重构的最好战场。

原文来自：http://www.affecthing.com/20190615/refactoring/

链接: https://www.fly63.com/article/detial/3737