Refresh 重构(Refactor)

最近在闲暇之余重(第)温(一..次)此书, 首先能感受到的, 无论你是新程序员还是老程序员, 这本书都已经不具备太多的可读性了.

由于本书成书年代久远, 那个时候软件行业还不够发达, 面向对象还没有被大数人理解, 加之编译器也非常落后, 设计模式也不深入人心, 所以文中提供的所谓重构的心法, 在当时或许有一些意义. 而今看来, 整书400多页的文字, 主要的思想就是「抽」, 无论是类, 接口, 方法, 逻辑, 还是参数. 但是为什么会有这么大的篇幅, 其中一半的内容是教你如何在一个IDE功能匮乏的年代, 以一个出错率更低的顺序, 来进行上面所说的多种抽象操作.

当然我去除了大量书中已经没有任何价值的点后, 总结了如下的一些内容, 应该大多数大家已经在工作实践中已有体会, 主要还是总结一下, 温故知新吧.

• 思想方面
  • 如果发现加特性很难, 就需要重构
  • 重构前需要想想有没有可靠的测试机制
  • 重构要微小步伐, 容易发现错误
  • Extract method是最简单的重构
  • 写出机器认识的代码容易, 写出人类容易理解的才是应该的, 最大的影响就是命名
  • 做移动重构时, 最好先复制粘贴, 测后再删除旧的代码
  • 对于另外对象的switch往往可以通过继承, 多态来取代
  • 三次遇到不合理的, 可能就是重构的时候了
  • 重构往往通过加隔离层进行
  • 不要过早发布接口
  • 性能优化应该基于良好的代码结构, 性能瓶颈往往只会在很小的代码片段里
  • 每次遇到一个bug, 尽量写个单元测试覆盖
  • 测试集中覆盖边缘case
• 代码坏味道与手段
  • 重复代码
    • 抽方法
  • 大函数
    • 抽方法, 抽类
  • 大类
    • 抽类, 抽子类
  • 太多参数
    • 参数变方法, 抽参数对象
  • 加新功能修改多个函数
    • 抽子类
  • 加新功能需要改很多类
    • 挪方法, 挪成员
  • 函数过度依赖其他类
    • 挪方法, 抽方法
  • 同样的几个参数到处出现
    • 抽参数对象
  • 大量同样的基本类型做参数
    • 抽类, 不同表达式可抽进子类
  • 很多switch
    • 考虑用多态取代
  • 子类需平行同时添加
    • 先持有对方, 再挪方法, 再挪变量, 再合并
  • 没人用的类
    • 做内部类
  • 没太大用处的抽象, 参数, 命名
    • 删除, 重命名, 内联
  • 临时变量命名模糊
    • 抽方法, 抽类
  • 消息链过长, 对象转换过多
    • 对同一对象的使用抽方法, 推入消息链消除对象
  • 过度代理
    • 内联代理
  • 注释太多
    • 可能代码写的太难懂, 需要重构
• 数据
  • 临时变量被赋值多次, 则可以抽成方法
  • 有时候需要提取多个临时变量对逻辑进行解释, 当然更好的可以再抽成方法
  • Java按值传递, 本质上是对象的引用按值传递
  • 移除中间人与隐藏委托是相辅相成的
  • 如果类无法更改, 就写个函数包装他, 类似于工厂方法?
  • 如果不能修改, Adapter模式常常用于扩展方法功能
  • 子类修改某些变量的获取可以通过自封装, 把变量抽象成函数
  • 成员如果不用改变, 就由引用变为值对象, 即immutable对象
  • 当业务复杂度变高需要将类之间单向关系改为双向绑定关系, 甚至一对多与多对一的关系
  • 双向绑定可能会造成很多僵尸对象, 增加复杂度与空间占用, 所以只有真正需要的时候用, 删除可以通过将内部绑定查询转移为传参, 再在调用的位置进行判断是否为僵尸对象
  • 不要使用Magic Number, 常量即可以优化储存, 又可读性高
  • 封装字段可以控制字段的读写, 称之为数据隐藏
  • 对于返回集合的函数需要返回只读副本, 如果需要修改, 则可另行提供修改方法
  • 原始类型替换成类, 有类型字段的类转换为多个子类, 或者抽象成策略模式, 从而合理改变数据结构
  • 如果子类只有常量, 可以抽成变量放父类, 再添加工厂方法创建, 降低复杂度
• 条件表达式
  • 条件表达式很复杂的时候, 可以将条件, 执行代码进行封装, 更表意
  • 嵌套很深的条件表达式的每个结果都作为返回值的话, 可以简化为多个if+return, 类似于swift里面的guard, 或者kotlin里面的?:return, 书里叫卫语句(Guard Clauses)
  • 嵌套很深的条件表达式可以将范围大的if反向, 实现提前return
  • switch表达式有时候可以通过多态来取代
• 函数调用
  • 函数最好读写分离
  • 抽象重复性的函数用以复用
  • switch构造可以替换成工厂方法
  • 从对象内拿出参数再传递给某函数不如直接将对象传入函数
  • 当函数的参数来自另外一个函数时, 也可以删掉参数, 把函数调用挪进去
  • 函数参数过多可以同对象替代
  • 如果不需要设置就不要提供set方法, 变量都需要为final
  • 有时候用抛异常替代返回错误码, 如果程序无法继续进行的话
  • 如果可以条件逻辑避免Runtime异常, 应不要无脑try/catch
• 继承关系
  • 子类同样的方法应该向上提, 并将不同的地方抽象为抽象方法分别继承
  • 子类构造复制父类字段应该通过父类构造, super
  • 超类与子类差不多, 就合并
  • 逻辑相同, 类型不同可以通过模板函数, 模板类解决
  • 不能滥用继承, 组合代理好过继承, 但也有特殊, 如果需要使用委托函数所有函数或者大量, 则就需要继承, 不过这一点在kotlin里面也可以通过by来代理
• 复杂的重构
  • 整理复杂的继承关系, 该抽接口抽接口, 摘出更多深层子类
  • 领域与表述分离, 就是UI与逻辑分离
  • 过程抽象为对象
  • 提炼继承体系