代码重构 Skill

这是一个基于 Martin Fowler《Refactoring: Improving the Design of Existing Code》（第 2 版）的系统化代码重构方法。这个 skill 强调安全、渐进的修改，并由测试提供保障。

“重构是在不改变软件外部行为的前提下，改进其内部结构的过程。”, Martin Fowler

核心原则

1. 保持行为不变：外部行为必须保持一致
2. 小步前进：每次只做很小、可测试的改动
3. 测试驱动：测试是安全网
4. 持续进行：重构是长期过程，不是一次性任务
5. 协作确认：每个阶段都需要用户确认

工作流程总览

阶段 1：研究与分析
    ↓
阶段 2：测试覆盖评估
    ↓
阶段 3：识别代码异味
    ↓
阶段 4：创建重构计划
    ↓
阶段 5：增量实施
    ↓
阶段 6：评审与迭代

---

阶段 1：研究与分析

目标

• 理解代码库结构和用途
• 确定重构范围
• 收集业务需求背景

先向用户确认的问题

开始前先确认：

1. 范围：哪些文件 / 模块 / 函数需要重构？
2. 目标：你想解决什么问题？（可读性、性能、可维护性）
3. 约束：有哪些区域不能改？
4. 时间压力：这是否阻塞了其他工作？
5. 测试状态：是否已有测试？是否通过？

行动

• 阅读并理解目标代码
• 识别依赖和集成点
• 记录当前架构
• 标记已有技术债迹象（TODO、FIXME）

输出

向用户汇报：

• 代码结构总结
• 识别出的问题区域
• 初步建议
• 请求继续执行的批准

---

阶段 2：测试覆盖评估

为什么测试重要

“没有测试的重构，就像没有安全带就开车。”, Martin Fowler

测试是安全重构的关键前提。没有测试，很容易引入 bug。

评估步骤

1. 检查现有测试

   # 查找测试文件
   find . -name "*test*" -o -name "*spec*" | head -20
   

2. 运行现有测试

   # JavaScript / TypeScript
   npm test
   
   # Python
   pytest -v
   
   # Java
   mvn test
   

3. 检查覆盖率（如果可用）

   # JavaScript
   npm run test:coverage
   
   # Python
   pytest --cov=.
   

决策点：询问用户

如果测试存在且通过：

• 进入阶段 3

如果测试缺失或不完整： 给出选项：

1. 先写测试（推荐）
2. 在重构过程中逐步补测试
3. 不写测试直接继续（有风险，需要用户确认）

如果测试失败：

• 停止。先修复失败测试再重构
• 问用户：是否先修测试？

测试编写建议（如需要）

对每个要重构的函数，测试应覆盖：

• 正常路径
• 边界情况（空输入、null、边界值）
• 错误场景（非法输入、异常）

使用“红-绿-重构”循环：

1. 写失败测试（红）
2. 让它通过（绿）
3. 再重构

---

阶段 3：识别代码异味

什么是代码异味？

代码深层问题的表面症状。它们不一定是 bug，但说明代码设计可能有问题。

常见异味清单

完整目录见 references/code-smells.md。

快速参考