共计 985 个字符,预计需要花费 3 分钟才能阅读完成。
本文属于原创文章,转载请注明 – 来自桃源小盼的博客
代码不可能在第一次就写得完美,这是一个持续修改的过程,那么应该怎么来进行呢?
以下内容来自 《重构 - 改善既有代码的设计》
是什么
- 好代码的检验标准就是人们是否能轻而易举地修改它。
- 由于预先做出良好的设计非常困难,想要既体面又快速地开发功能,重构必不可少。
- 重构的意义就在于:你永远不必说对不起,只要把出问题的地方修补好就行了。
- 重构过程的精髓所在:小步修改,每次修改后就运行测试。
- 重构的最佳时机就在添加新功能之前。
- 我不专门安排一段时间来重构,而是在添加功能或修复 bug 的同时顺便重构。
- 与其猜测未来需要哪些灵活性,需要什么机制来提供灵活性,我更愿意只根据当前的需求来构造软件。
做什么
- 数据结构才是一个健壮程序的根基。
- 消除重复。
- 函数是我们将程序拆分成小块的主要方式。
- 根据一个函数的意图(做什么)来对它命名。
- 只要改名能够提升代码的可读性,那就应该毫不犹豫去做。
- 如果某些数据和某些函数总是一起出现,某些数据经常同时变化甚至彼此相依,这就表示你应该将它们分离出去 (比如提炼类)。
- 一个好的模块化的设计,” 封装 ” 是最关键的特征之一。” 封装 ” 意味着每个模块都应该尽可能少了解系统的其他部分。
- 尽量遵循命令与查询分离原则。
- 大部分条件逻辑只用到了基本的条件语句,但如果发现复杂条件逻辑,多态是改善这种情况的有力工具。
- 合理的继承关系是在程序演化的过程中才浮现出来的:我发现了一些共同元素,希望把它们抽取到一处,于是就有了继承关系。
注意什么
- 数据被使用得越广,就越是值得花精力给它一个体面的封装。
- 如果可访问范围变大,重构的难度就会随之增大,这也是说全局数据是大麻烦的原因。
- 将一个值用于多个不同的用途,这就是催生混乱和 bug 的温床。
- 如果你不知道该做什么,这才是注释的良好运用时机。
- 重构过程的性能问题:大多数情况下可以忽略它,如果有性能损耗,先完成重构,再做性能优化。
- 如果重写比重构还容易,就别重构了。
一直在追问自己要不要总结一篇这样偏理论性的文章。其实大部头的书不太容易静下心来读,那么我就把一些基本的知识晒出来,让看到的人产生思考,然后能去读原书。就算不读这本 421 页的《重构》也能对重构有一个基本的了解,方便在日后遇到问题时,知道去哪里寻找答案。
原书总结了常用的上百种重构手法,如果真正理解了什么是重构,自己也可以创造一些手法,实际的业务场景才是重构的最好战场。
正文完