重构

重构

基于软件开发周期和代码质量，对重构的关注点做如下分类：

关注点	解释	影响方面
可读性	代码是否易于理解和阅读，命名是否清晰直观	开发效率、团队协作、知识传递、代码审查
可维护性	代码是否易于修改和扩展，变更成本的高低	维护成本、迭代速度、bug修复效率、技术债务
可测试性	代码是否易于编写测试用例，测试的隔离性	质量保障、回归测试、持续集成、重构安全性
可靠性	代码在运行时的稳定性和错误处理能力	系统稳定性、用户体验、故障恢复、生产环境表现
可扩展性	代码适应未来需求变化的能力	业务演进、功能扩展、技术升级、架构演进
内聚性	模块内部元素功能相关的紧密程度	代码组织、职责清晰度、变更影响范围、理解成本
封装性	信息隐藏和数据访问控制的程度	模块边界、依赖管理、接口稳定性、修改安全性
耦合度	模块间相互依赖的程度和方式	系统复杂度、独立部署能力、测试难度、变更影响

重构衡量标准

1. 影响基础和稳定性

问题	解释	关注点	解决方案
重复代码	修改时容易遗漏	可维护性/可靠性	封装为方法/类 虚基类实现多态：多个类中包含相同步骤
过长函数	难以理解、测试和维护	可读性/可测试性	提取函数 分解计算过程/条件表达式
神秘命名	影响代码可读性，增加团队沟通成本	可读性/可维护性	是什么&&做什么
全局数据	导致不可预测的副作用，使测试和调试极其困难	可测试性/可靠性	依赖注入 写到配置文件中

依赖注入：依赖由外部传入，而不是内部创建，就是对象属性通过参数初始化

2. 改善代码质量

问题	解释	关注点	解决方案
过大的类	过耦合、边界模糊，难以理解和修改	可读性/可维护性	提取类 提取专用接口
数据泥团	多处相同字段（包含参数列表）和函数	可维护性/可读性	提取参数对象 提取类
switch语句	重复的switch，一处修改意味着多处修改	可扩展性/可维护性	多态 策略模式
依恋情结	一个方法过度访问另一个对象的数据	可维护性/封装性	搬移方法 提取方法到新类

3. 改善代码设计

问题	解释	关注点	解决方案
过长参数列	函数参数过多，难以理解和使用，容易传参错误	可读性/可靠性	提取/引用参数对象
基本类型偏执	过度使用基本类型而不是创建适当的领域对象	可维护性/可靠性	用对象替换基本类型 引入类型别名
发散式变化	一个类因为不同原因在不同的方向上发生变化	内聚性/可维护性	提取类/方法
数据类	类只有数据字段和getter/setter，没有业务行为	内聚性/封装性	散落在类外的业务封装回去

4. 影响小，开发时注意即可

问题	解释	解决方案
霰弹式修改	修改分散，但影响程度因项目而异
过度耦合的消息链	a.getB().getC().doSomething() 的链式调用
不恰当的亲密性	类之间过度了解内部细节
令人迷惑的暂时字段	字段只在某些情况下使用，混淆对象状态
中间人	过度委托，但有时是必要的设计模式
异曲同工的类	接口不一致，但功能正确
平行继承体系	设计问题，但不一定立即影响功能
被拒绝的遗赠	继承设计不当，但可能暂时工作正常
冗赘类	可能是预留扩展，删除需谨慎
夸夸其谈未来性	过度设计，但可能体现设计者的思考
不完美的库类	外部依赖，重构受限制
过多的注释	注释多不一定是坏事，要看内容质量