如何进行重构

  • 对象行为改变的因素一定要是直接受到影响，不要跨级影响。
  • 添加完整的注释
  • 重写非单一职责的类、方法
  • 涉及到表级的改动影响比较大，需要特别慎重
  • 全局变量有妙用，但需慎用

例　　

　　假定这样一个场景应用上显示前后两个数字，当个位上的值大于十就将前面的数字加一。初始场景只有一个“加十”按钮。于是对于“加十”按钮最简单的实现就是直接对头部的数字直接加一，看上去没有问题但实际上已经在我们的代码中埋下了技术债。

　　后期如果出现了功能“加二十”，就需要对原有方法进行改动，妹添加一个功能就需要一次改动，循环往复。但一开始“加十”影响的就是数值，影响头部数字的只是数值就不会遗留这些问题。

何时进行重构

  1. 命名不规范
  2. 代码重复
  3. 方法过长，类过大
  4. 难以扩展
  5. 可读性差
  6. 代码间出现强耦合
  7. 性能出现瓶颈，时间复杂度
  8. 行为是否统一
    • 缓存是否统一
    • 错误处理是否统一
    • 错误提示是否统一
    • 弹出框是否统一

案例一：去间接表述

代码示例

var index = accessibleNode.GetIndexInParent();
if (index > -1)
{
　　Id = string.Format("{0}({1})", Role, index);
}

解释说明

对于accessibleNode对象有三个子类，其中两个子类的 GetIndexInParent 没有重写，默认返回值都是-1.

潜在风险

 index > -1 实际上的含义是： accessibleNodeisxxSub 

首先通过 index > -1 来处理可读性很差，其次日后若其他子类重写了 GetIndexInParent() 就会改变这段代码的效果

其他说明

  • 引用外部的方法添加一层包装
  • 消除全局变量，对于全局变量最好是Readonly
  • 分析移除以结果导向创建的函数
  • 站在巨人的肩膀上我们往往会犯错，记得考驾照时教练交代过路口时要踩刹车使速度降到30以下，我错误的理解成了考试规范，实际上是过路口速度不能超过30，就先减速后加速错过了一次重要的机会。对于我们常用的设计模式来说，都是巨人们的肩膀，稍有不慎就弄巧成拙