重构 阅读笔记

重构阅读笔记

• 重构测试：每一小步进行，程序最好具有自我检验的测试机制（代码控制输入，对比标准的参考输出），减少人为比对（安卓使用吗？）

• Extract Method

  • 从较长的方法中抽取出逻辑

• 方法内重命名，让代码表意清晰

• Move Method

  • 函数应该放在它所用的数据的所属对象

• 旧函数位置被替换后，如果其为public并且多处使用，可以将它内部替换为使用新函数（标记弃用）

• Repalce Temp with Query

  • 避免过多使用临时变量，回导致大量参数被传来传去，使用查询替代哪怕回存在重复的计算（？）
    • 过深的方法栈传参是否可以使用查询？早期使用可能会过度设计？

• 对其他对象数据的使用

  • 最好不要对其他对象的属性基础上使用switch之类的复杂判断，不得不使用也应再对象自己的数据上使用，而不是再别人的数据上使用

• 某一项计算依赖A（不稳定）、B（稳定）两个类的数据，可选择将计算的方法放在A（将B的数据传给A，由A的方法计算)，可以考虑在后续业务中A或B的预期变化量，将方法给具有不稳定倾向的类A; B中若需要同名方法,可以用A的方法实现

  否则A在变更字段后需要定位到B或更多相关的类中修改？

• 传参使用多参数/封装成类

  • 使用对象传参可以在未来通过对象获取更多参数，而不用给方法扩展参数，且易于理解
  • 不希望方法依赖于对象时，使用参数传参

需要重构的现象

• 散弹式修改

  • 某种变化导致需要在四处做细小的修改（容易忘记重要的修改），可以将相关代码放入同一个类
    • 如InsP的可变比例在UI 、渲染、编辑中需要的改动

• switch语句

  • 同样的switch语句在多出调用，没新增一种case，都对应在各处去添加case子句 -> 使用多态替代

    如InsP的可变比例导致的各项特殊判断，可封装成类，使用多态

• Data Class

  • 单纯的数据类需要检查封装，不该由setter的需要去除，尽量不使用public
  • 寻找取值、设置函数的使用，看是否能够抽出位该数据类的内部方法

• 启发性总结：

  • 所有事物和行为只在代码中表述一次时优秀设计的根本

  • 未完全理整体设计前旧贸然修改代码，会导致程序逐渐失去自己的结构，越来越难通过于都源码理解原来的设计

    需要完整理解设计，在设计或优化设计的基础上添加代码

  • 重构使程序易于理解后（“擦掉窗户上的污垢”），可以更清晰的看到设计的更深层次

  • 糟糕的设计会导致调试、添加新功能的时间变长，花费更多时间理解系统、寻找重复代码、打上多个补丁

  • 重构的三次法则