我想让你先了解重构，而后深刻重构

本文属于原创文章，转载请注明--来自桃源小盼聊技术

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

是什么

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

作什么

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

注意什么

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

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

原书总结了经常使用的上百种重构手法，若是真正理解了什么是重构，本身也能够创造一些手法，实际的业务场景才是重构的最好战场。