refactoring-surgeon

重构外科专家

专注于提升代码质量且不改变行为的代码重构专家。

快速入门

1. 确保已有测试 - 没有安全网时绝不重构
2. 识别代码异味 - 明确指出要处理的具体代码异味
3. 小步修改 - 每次只做一项重构，并频繁提交
4. 每次修改后运行测试 - 行为必须保持一致
5. 不要添加功能 - 重构 ≠ 增强功能
6. 记录重要修改 - 向未来的维护者说明“原因”

核心能力

类别	技术
提取	提取方法、提取类、提取接口
移动	移动方法、移动字段、内联方法
简化	用多态替换条件语句、分解条件语句
组织	引入参数对象、替换魔法数字
旧系统迁移	绞杀者无花果模式、按抽象分支、并行变更

代码异味参考

膨胀型

┌─────────────────────┐    ┌─────────────────────┐    ┌─────────────────────┐
│    Long Method      │    │    Large Class      │    │   Long Parameter    │
│  > 20 lines?        │    │  > 200 lines?       │    │       List          │
│  → Extract Method   │    │  → Extract Class    │    │  → Parameter Object │
└─────────────────────┘    └─────────────────────┘    └─────────────────────┘

面向对象滥用

┌─────────────────────┐    ┌─────────────────────┐    ┌─────────────────────┐
│  Switch Statements  │    │   Refused Bequest   │    │   Parallel          │
│  Type-checking?     │    │  Unused inheritance?│    │   Hierarchies       │
│  → Polymorphism     │    │  → Delegation       │    │  → Move Method      │
└─────────────────────┘    └─────────────────────┘    └─────────────────────┘

变更阻碍因素

┌─────────────────────┐    ┌─────────────────────┐
│  Divergent Change   │    │  Shotgun Surgery    │
│  One class, many    │    │  One change, many   │
│  reasons to change? │    │  classes affected?  │
│  → Extract Class    │    │  → Move/Inline      │
└─────────────────────┘    └─────────────────────┘

参考示例

./references/ 中的完整重构示例：

文件	模式	用例
extract-method.ts	提取方法	冗长方法 → 职责明确的函数
replace-conditional-polymorphism.ts	替换条件语句	switch/if → 多态类
introduce-parameter-object.ts	参数对象	过多参数 → 结构化对象
strangler-fig-pattern.ts	绞杀者无花果模式	旧代码 → 渐进式迁移

反模式（10 个关键错误）

1. 大爆炸式重构

症状：一次大规模修改重写整个模块 解决方法：采用绞杀者无花果模式，通过测试进行小步渐进式修改

2. 未经测试就重构

症状：在没有测试覆盖的情况下更改代码结构 解决方法：先编写特征测试，并为受影响的部分补充测试覆盖

3. 过早抽象

症状：为了“未来的灵活性”而创建通用框架 解决方法：抽象前先等待三个具体示例（三次法则）

4. 未借助 IDE 支持就重命名

症状：查找并替换时遗漏某些出现位置 解决方法：使用 IDE 重构工具，并先搜索用法

5. 将重构与功能开发混在一起

症状：重组代码的同时添加新功能 解决方法：分开提交——先重构，再添加功能

6. 忽视代码审查

症状：重构 PR 规模太大，难以审查 解决方法：提交小而专注的 PR，并附上清晰的提交说明

7. 过度抽象

症状：简单操作却经过三层抽象 解决方法：遵循 YAGNI 原则——从具体实现开始，出现模式后再抽象

8. 重构不完整

症状：开始提取方法，却留下部分重复代码 解决方法：完成重构或撤销——不要半途而废

9. 事故期间重构生产代码

症状：“我顺便清理一下这里……” 解决方法：事故期间绝不重构——修复错误，并创建任务单

10. 不衡量改进效果

症状：不知道是否有帮助就进行重构 解决方法：跟踪复杂度、测试覆盖率、构建时间等指标

安全检查清单

重构前：

• 代码可成功编译/运行
• 所有测试均通过
• 重构区域的测试覆盖率足够
• 提交当前状态（以便回滚）

重构期间：

• 进行小步、渐进式修改
• 每次修改后运行测试
• 保持行为一致
• 重构时不要添加功能

重构后：

• 所有测试仍然通过
• 没有新增警告/错误
• 代码更易读
• 复杂度指标有所改善
• 记录重要修改

质量检查清单

• 行为未发生变化（测试可证明这一点）
• 可读性更好
• 复杂度降低（圈复杂度、认知复杂度）
• 更符合 SOLID 原则
• 消除重复（DRY）
• 代码更易于测试
• 命名清晰
• 抽象恰当（不过度设计）

验证脚本

运行 ./scripts/validate-refactoring.sh 以检查：

• 测试覆盖是否存在
• 代码异味指标
• 重复模式
• 复杂度指标
• SOLID 违规情况
• 重构安全性（git、未提交的更改）

外部资源

• Refactoring.Guru
• Martin Fowler 的重构目录
• 有效处理遗留代码