refactoring-workflow

name	refactoring-workflow
description	基于 Martin Fowler《重构》第二版的渐进式重构工作流。六步法（嗅探→排序→保护→改造→审查→收尾），每次只用一个手法，测试始终绿灯。Use when 用户说重构/改善代码质量/优化结构/debt/坏味道，MDD task 涉及重构步骤，或需要系统性地清理代码。

渐进式重构工作流

基于 Fowler 的核心理念：小步快走，测试覆盖，一次只改一件事。

前提条件

• 明确的重构范围（文件/目录/模块）
• 版本控制干净（没有未提交的无关改动）
• 不能同时改功能和重构（分开做）

六步工作流

嗅探 → 排序 → 保护 → 改造 → 审查 → 收尾

第一步：嗅探（Smell Detection）

目标：扫描目标代码，列出所有坏味道及其位置。

操作：

1. 读取目标文件/模块
2. 对照 refactoring-reference 的坏味道清单逐条检查
3. 输出嗅探报告，每条记录：坏味道类型、位置（文件:行号）、严重程度（高/中/低）、违反原因

输出格式：

| # | 坏味道 | 位置 | 严重 | 说明 |
|---|--------|------|------|------|
| 1 | 长函数 | xxx.vue:45-120 | 高 | 函数 75 行，做 3 件事 |
| 2 | 重复代码 | a.vue:10 b.vue:15 | 中 | 相同的计算逻辑 |

第二步：排序（Prioritize）

目标：按影响范围从窄到宽排列，先内后外。

排序原则：

1. 先函数内部 — 提炼函数、变量改名、卫语句（影响范围：单函数）
2. 再类/组件内部 — 搬移字段、拆分阶段（影响范围：单文件）
3. 后模块之间 — 搬移函数、提炼类（影响范围：多文件）
4. 最后全局 — 改名、API 重构（影响范围：全局）

每次只做一种坏味道的清理。

第三步：保护（Safety Net）

目标：确保有测试保护，没有就补。

检查清单：

• 目标代码有单元测试覆盖？如果没有 → 先写 characterization test（刻画测试，记录当前行为）
• 测试在当前代码上通过？没通过 → 先修测试，不继续
• 测试在改动后能快速运行？不能 → 考虑只运行相关测试子集

第四步：改造（Refactor）

核心规则：每次只用一个手法，改完立刻跑测试。

操作循环（重复直到该项坏味道消除）：

1. 选择最窄影响范围的手法
2. 实施改动（改代码）
3. 立即运行测试
4. 测试通过 → 继续下一个子步骤
5. 测试失败 → 撤销回上一步，用更小的步子

步子太小不是问题，步子太大才是。

第五步：审查（Review）

目标：对照气味清单自检残留。

检查清单：

• 对照第一步的嗅探报告，逐条确认已处理
• 是否有新引入的坏味道？（提炼过度、中间人等）
• 命名是否准确表达意图？
• 函数长度是否合理（< 20 行为佳）？
• 是否保留了原有注释？（如果注释在解释 WHAT → 用好的命名替代；如果解释 WHY → 保留）

第六步：收尾（Close）

• 运行完整测试套件
• 运行类型检查（vue-tsc --noEmit）
• 对比改动前后的 diff，确认没有意外修改
• 提交 commit，commit message 描述重构意图而非逐条列举改动
• 更新重构 spec（如有 MDD task）

---

实战检查清单

每次重构抄这个：

□ 1. 重构范围已确认？
□ 2. 嗅探报告已出？列出 ___ 个坏味道
□ 3. 排序完成？按影响范围从窄到宽
□ 4. 测试绿灯？（先跑一次）
□ 5. 当前正在处理：___（只填一个坏味道）
□ 6. 每改一小步就跑测试？
□ 7. 审查完成？无新坏味道
□ 8. 全量测试通过？
□ 9. commit 已提交？