重构的基本认知

本文属于原创文章,转载请注明–来自桃源小盼的博客

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

是什么

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

做什么

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

注意什么

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

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

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