基于 Martin Fowler 方法论的系统化代码重构 skill。适用于用户请求重构代码、改进代码结构、减少技术债、清理旧代码、消除 code smell 或提升可维护性时。这个 skill 采用分阶段、带研究与计划的安全增量实施方式。
这是一个基于 Martin Fowler《Refactoring: Improving the Design of Existing Code》（第 2 版）的系统化代码重构方法。这个 skill 强调安全、渐进的修改，并由测试提供保障。
“重构是在不改变软件外部行为的前提下，改进其内部结构的过程。” — Martin Fowler
阶段 1：研究与分析
↓
阶段 2：测试覆盖评估
↓
阶段 3：识别代码异味
↓
阶段 4：创建重构计划
↓
阶段 5：增量实施
↓
阶段 6：评审与迭代
开始前先确认：
向用户汇报：
“没有测试的重构，就像没有安全带就开车。” — Martin Fowler
测试是安全重构的关键前提。没有测试，很容易引入 bug。
检查现有测试
# 查找测试文件
find . -name "*test*" -o -name "*spec*" | head -20
运行现有测试
# JavaScript / TypeScript
npm test
# Python
pytest -v
# Java
mvn test
检查覆盖率（如果可用）
# JavaScript
npm run test:coverage
# Python
pytest --cov=.
如果测试存在且通过：
如果测试缺失或不完整： 给出选项：
如果测试失败：
对每个要重构的函数，测试应覆盖：
使用“红-绿-重构”循环：
代码深层问题的表面症状。它们不一定是 bug，但说明代码设计可能有问题。
完整目录见 references/code-smells.md。
| 异味 | 迹象 | 影响 |
|---|---|---|
| 长函数 | 函数超过 30-50 行 | 难以理解、测试和维护 |
| 重复代码 | 多处出现相同逻辑 | 修复需要改多处 |
| 大类 | 类承担了太多职责 | 违反单一职责原则 |
| Feature Envy | 一个方法更多依赖别的类的数据 | 封装性差 |
| 基础类型沉迷 | 过度使用基础类型而不是对象 | 缺少领域概念 |
| 长参数列表 | 方法参数超过 4 个 | 调用困难 |
| 数据泥团 | 一组数据总是一起出现 | 缺少抽象 |
| switch 语句 | 复杂的 switch / if-else 链 | 难以扩展 |
| 臆想泛化 | “以防未来需要”提前设计 | 不必要的复杂度 |
| 死代码 | 未使用的代码 | 造成困惑和维护负担 |
自动分析（如果有脚本）
python scripts/detect-smells.py <file>
人工审查
优先级排序 优先关注会：
向用户呈现：
针对每个异味，从目录中选择合适的重构手法。
| 代码异味 | 推荐重构 |
|---|---|
| 长函数 | Extract Method、Replace Temp with Query |
| 重复代码 | Extract Method、Pull Up Method、Form Template Method |
| 大类 | Extract Class、Extract Subclass |
| Feature Envy | Move Method、Move Field |
| 基础类型沉迷 | Replace Primitive with Object、Replace Type Code with Class |
| 长参数列表 | Introduce Parameter Object、Preserve Whole Object |
| 数据泥团 | Extract Class、Introduce Parameter Object |
| switch 语句 | Replace Conditional with Polymorphism |
| 臆想泛化 | Collapse Hierarchy、Inline Class、Remove Dead Code |
| 死代码 | Remove Dead Code |
使用 templates/refactoring-plan.md 里的模板。
每项重构都要写明：
关键：重构必须分阶段推进。
阶段 A：快速收益（低风险，高价值）
阶段 B：结构改进（中风险）
阶段 C：架构改动（高风险）
在开始实施前：
“修改 → 测试 → 通过？→ 提交 → 下一步”
对每一步重构：
预检查
只做一个小改动
验证
如果测试通过（绿色）
如果测试失败（红色）
每次提交都应当：
示例提交信息：