「重构：改善既有代码设计」学习笔记
重构
不改变代码行为的情况下，对代码做出修改，改进程序的内部结构
重构时机
- 时机：事不过三；添加新功能时；修补错误时；复核代码时
- 非时机：代码太混乱，与其重构不如重写；最后一分钟，deadline；工作量显著超标；没有更好的思路时
重构设计四原则
- 通过所有测试：软件系统对外部需求被正确地完成，包括功能性需求和非功能性需求，并通过了客户验收的标准
- 尽可能消除重复：让软件走向高内聚，低耦合，达到良好正交性的过程，并不是所有的重复都可以消除，这条原则被描述为最小化重复，而不是消除重复
- 尽可能清晰表达：漂亮的代码如同优美的散文，从不隐藏设计者的意图，恰如其分的抽象，直截了当的控制，代码被阅读的次数远远大于其修改的次数
- 更少的代码元素：尽可能的降低设计的复杂度，保持简单
代码坏味道层次
- 直观：一眼过去就可以看到问题，比如魔鬼数字，函数或类过长，圈复杂度高，函数或变量命名不规范
- 微观：需要仔细检查才能发现的问题，比如类字段定义不合理，函数功能不单一，变量作用域过长等问题
- 宏观：代码架构上的整体问题，比如类的职责不惮以，上帝类，分层不清楚，上下文混乱等问题
代码坏味道：冗余和重复
- 重复
- 同一个类，两个函数有重复，提取公共代码
- 互为兄弟的子类中有重复，提取公共代码，pull至父类
- 毫不相干的类有重复，提取到工具类中
- 过多的注释，考虑提取方法，命名通俗易懂的函数名
- 夸夸其谈未来性
代码坏味道：局部膨胀
- 过长参数列表
- 一个参数通过另一个参数查到，考虑使用查询函数取代参数
- 多个参数属于同一个数据结构时，封装成对象
- 多个参数有关联，总是同时使用，封装成对象
- 某个参数是用来区分函数行为的，可以考虑移除
- 多个函数有相同的参数，可以将多个函数组合成类
代码坏味道：耦合结构不良
- 发散式变化：模块功能过多
- 霰弹式修改：遇到某种变化，多个不同的模块需要修改
- switch惊悚现身：写出只做一件事的 switch 语句也很难， switch 天生要做 N 件 事
[1]: 重构: 改善既有代码设计， Martin Fowler.