Skip to content
目录

「重构:改善既有代码设计」学习笔记

重构

不改变代码行为的情况下,对代码做出修改,改进程序的内部结构

重构时机

  • 时机:事不过三;添加新功能时;修补错误时;复核代码时
  • 非时机:代码太混乱,与其重构不如重写;最后一分钟,deadline;工作量显著超标;没有更好的思路时

重构设计四原则

  • 通过所有测试:软件系统对外部需求被正确地完成,包括功能性需求和非功能性需求,并通过了客户验收的标准
  • 尽可能消除重复:让软件走向高内聚,低耦合,达到良好正交性的过程,并不是所有的重复都可以消除,这条原则被描述为最小化重复,而不是消除重复
  • 尽可能清晰表达:漂亮的代码如同优美的散文,从不隐藏设计者的意图,恰如其分的抽象,直截了当的控制,代码被阅读的次数远远大于其修改的次数
  • 更少的代码元素:尽可能的降低设计的复杂度,保持简单

代码坏味道层次

  • 直观:一眼过去就可以看到问题,比如魔鬼数字,函数或类过长,圈复杂度高,函数或变量命名不规范
  • 微观:需要仔细检查才能发现的问题,比如类字段定义不合理,函数功能不单一,变量作用域过长等问题
  • 宏观:代码架构上的整体问题,比如类的职责不惮以,上帝类,分层不清楚,上下文混乱等问题

代码坏味道:冗余和重复

  • 重复
    • 同一个类,两个函数有重复,提取公共代码
    • 互为兄弟的子类中有重复,提取公共代码,pull至父类
    • 毫不相干的类有重复,提取到工具类中
  • 过多的注释,考虑提取方法,命名通俗易懂的函数名
  • 夸夸其谈未来性

代码坏味道:局部膨胀

  • 过长参数列表
    • 一个参数通过另一个参数查到,考虑使用查询函数取代参数
    • 多个参数属于同一个数据结构时,封装成对象
    • 多个参数有关联,总是同时使用,封装成对象
    • 某个参数是用来区分函数行为的,可以考虑移除
    • 多个函数有相同的参数,可以将多个函数组合成类

代码坏味道:耦合结构不良

  • 发散式变化:模块功能过多
  • 霰弹式修改:遇到某种变化,多个不同的模块需要修改
  • switch惊悚现身:写出只做一件事的 switch 语句也很难, switch 天生要做 N 件 事

重构



[1]: 重构: 改善既有代码设计, Martin Fowler.


Released under the MIT License.