Skills: 重构技能
最后更新：2026-08-31
重构不是重写——它是在不改变行为的前提下改善代码结构。Skill 让重构有章可循。
1. 代码坏味道识别
(1) 常见坏味道
| 坏味道 | Grep 模式 | 风险 |
|---|---|---|
| 过长函数 | 行数 > 50 | 🟡 |
| 重复代码 | 相似度 > 80% | 🟡 |
| 过深嵌套 | 嵌套层级 > 3 | 🟡 |
| 魔法数字 | 硬编码常量 | 🟢 |
| 上帝类 | 方法数 > 20 | 🔴 |
| 循环依赖 | 互相 import | 🔴 |
(2) 自动检测
YAML
---
name: smell-detector
description: "检测代码坏味道"
tools:
- Grep
- Glob
- Read
---
MARKDOWN
## 检测流程
1. Glob 获取文件列表
2. Grep 搜索坏味道模式
3. Read 深入确认
4. 按严重程度输出报告
2. 重构策略
(1) 重构手法对照
| 坏味道 | 重构手法 | 复杂度 |
|---|---|---|
| 过长函数 | 提取函数 | 🟢 低 |
| 重复代码 | 提取方法/模板方法 | 🟡 中 |
| 过深嵌套 | 卫语句/策略模式 | 🟡 中 |
| 魔法数字 | 提取常量 | 🟢 低 |
| 上帝类 | 拆分职责 | 🔴 高 |
| 循环依赖 | 引入接口/中介者 | 🔴 高 |
(2) 重构风险评估
TEXT
📖 仅展示
重构风险矩阵
影响范围小 影响范围大
改动量小 🟢 安全 🟡 需要测试
改动量大 🟡 需审查 🔴 需要分步
(3) 重构顺序原则
MARKDOWN
## 重构顺序
1. 先低风险后高风险（提取常量 → 提取函数 → 拆分类）
2. 先局部后全局（函数级 → 类级 → 模块级）
3. 每步可验证（小步前进，每步跑测试）
4. 可随时停止（任何一步后代码都应可工作）
3. 安全重构流程
(1) 重构前准备
MARKDOWN
## 前置检查
1. Bash: 运行全量测试，确认基准通过
2. Bash: git commit 当前状态（快照点）
3. Read: 理解重构目标的完整上下文
4. 识别所有调用点（谁依赖了这个代码）
(2) 执行重构
TEXT
📖 仅展示
安全重构循环
┌──────────────────┐
│ 1. 小步修改 │
│ 2. 运行测试 │
│ 3. 测试通过？ │
│ ├─ 是 → 继续 │
│ └─ 否 → 回滚 │
└──────────────────┘
(3) 重构后验证
MARKDOWN
## 验证清单
- [ ] 全量测试通过
- [ ] 功能行为未改变
- [ ] 代码更简洁/更清晰
- [ ] 无新增 TODO/FIXME
- [ ] 无循环依赖
4. 重构 Skill 实战
▶ 示例：安全提取函数
Alice 需要重构一个 200 行的长函数：
YAML
---
name: safe-extract-function
description: "安全提取函数"
tools:
- Read
- Edit
- Grep
- Bash
---
MARKDOWN
## 提取流程
1. Read 分析长函数，识别独立逻辑块
2. 列出提取计划（哪几行 → 新函数名）
3. 逐步执行：
a. Edit 在原函数下方创建新函数
b. Edit 修改原函数调用新函数
c. Bash 运行测试
4. 全部提取后运行全量测试
Bob 说："重构最怕的是改着改着功能就坏了——小步前进、步步验证，比一口气改完再测安全一万倍。"
❓ 常见问题
Q 重构时测试不通过怎么办？
A 立即回滚到上一步通过的状态，分析失败原因。常见原因：遗漏调用点、函数签名不兼容、隐式依赖。
Q 应该重构到什么程度？
A 满足团队规范即可，不要过度重构。目标是消除坏味道，不是追求完美架构。
Q 重构和功能开发能同时进行吗？
A 不建议。重构不改变行为，功能开发改变行为。两者混在一起会导致无法区分问题来源。
📖 小节
- 坏味道识别：用 Grep/Glob 模式匹配自动检测
- 重构策略：坏味道 → 重构手法对照，按风险排序
- 安全流程：基准测试 → 小步修改 → 步步验证 → 回滚保障
- 核心原则：每步可验证、可回滚、可停止
📝 作业
- 基础题（难度⭐）：创建一个坏味道检测 Skill，至少检测 3 种常见问题。
- 进阶题（难度⭐⭐）：创建一个安全提取函数 Skill，实现小步提取 + 步步验证的完整流程。
- 挑战题（难度⭐⭐⭐）：创建一个智能重构 Skill，能自动识别坏味道、选择重构手法、按安全顺序执行，并输出重构前后对比报告。
