B2 重构与测试
💡 一句话总结：用 AI 识别代码坏味道，安全重构，并自动生成测试用例。
📝 课程笔记
本课核心知识点整理：
学完你能做什么
- 让 AI 识别代码中的"坏味道"
- 安全地重构代码
- 自动生成单元测试
- 分析边界条件补充测试
你现在的困境
- 代码越写越乱，但不敢改怕改坏
- 想重构但没有测试保护
- 测试用例太少，覆盖率上不去
什么时候用这一招
- 当你需要：提升代码质量和测试覆盖率
- 而且不想：手动写大量测试用例
🎒 开始前的准备
确保你已经完成以下事项：
- [ ] 完成了 B1 开发日常
- [ ] 有一个需要重构或测试的代码文件
核心思路
重构安全三步法
1. 先有测试 → 2. 小步重构 → 3. 测试通过代码坏味道速览
| 坏味道 | 症状（经验信号） | 重构方向 |
|---|---|---|
| 函数过长 | 一眼看不完、混了多件事 | 提取函数/拆分职责 |
| 参数过多 | 调用方难以记住每个参数含义 | 引入参数对象/拆分函数 |
| 重复代码 | 相似逻辑在多处出现 | 提取公共函数 |
| 嵌套过深 | 读代码需要反复回溯条件 | 提前返回/提取条件判断 |
| 命名不清 | 无法从名字看出用途 | 重命名 |
跟我做
第 1 步：识别代码坏味道
为什么 先诊断，再治疗。
切换到 Plan Agent：
@src/utils/data.ts 请分析这个文件的代码质量：
1. 列出发现的"坏味道"
2. 每个问题的严重程度（高/中/低）
3. 推荐的重构方式
4. 重构的优先级建议第 2 步：先生成测试
为什么 有测试才能安全重构。
切换到 Build Agent：
@src/utils/data.ts 为这个文件生成单元测试：
1. 使用 Vitest 框架
2. 覆盖所有导出函数
3. 包含正常情况和边界情况
4. 保存为 src/utils/data.test.ts第 3 步：安全重构
为什么
小步重构，每步验证。
@src/utils/data.ts 请重构 parseUserData 函数：
- 问题：函数过长（50 行），职责不单一
- 要求：拆分成 3 个小函数
- 保持对外接口不变
- 重构后运行测试确认第 4 步：补充边界测试
为什么
边界条件往往是 Bug 高发区。
@src/utils/data.ts @src/utils/data.test.ts
分析代码的边界条件，补充以下测试：
1. 空输入（null、undefined、空数组）
2. 极值（超大数字、超长字符串）
3. 类型错误（传入错误类型）
4. 并发情况（如果有异步操作）第 5 步：运行测试验证
为什么
确认重构没有破坏功能。
在 OpenCode TUI 里，以
!开头的消息会执行 shell 命令，并把输出带进对话：https://opencode.ai/docs/tui
!npm test src/utils/data.test.ts你应该看到：所有测试通过
📋 魔法 Prompt
✅ 代码审查
预期效果：全面分析代码质量问题，给出改进建议
## 角色
你是技术负责人，负责把控代码质量。Review 风格是严格但建设性的。
## 任务
对提交的代码进行全面审查，发现问题并给出改进建议。
## 输入信息
### 必填项
- 编程语言：【编程语言】
- 代码：@【文件路径】 或 [粘贴代码]
### 选填项
- 审查重点：【重点关注的方面?】
- 项目背景：【代码的上下文?】
## 审查维度
1. **代码质量**：命名规范、代码结构、可读性、重复代码
2. **潜在问题**：Bug 风险、边界条件、错误处理、性能问题
3. **安全隐患**：输入验证、敏感信息、注入风险
4. **最佳实践**：设计模式、SOLID 原则、测试覆盖
## 输出规范
### 评审总结
- **代码评级**：A(优秀)/B(良好)/C(一般)/D(需重构)
- **一句话评价**
- **需修改才能合并**：是/否
### 问题列表
- 🔴 **严重问题**：`[文件:行号]` 问题 + 风险 + 建议
- 🟡 **建议改进**：推荐修复的问题
- 🟢 **优点**：值得保持的地方
## 约束条件
- ✅ 问题要具体到行号
- ✅ 每个问题都要有修复建议
- ✅ 肯定做得好的地方
- ❌ 避免主观偏好替代客观标准
- ❌ 避免只批评不给方案🧪 测试生成
预期效果：生成完整的单元测试，覆盖边界条件
## 角色
你是 QA 工程师，擅长设计全面的测试用例，覆盖正常流程和边界条件。
## 任务
为用户提供的函数或模块生成单元测试。
## 输入信息
### 必填项
- 编程语言：【语言】
- 代码：@【文件路径】 或 [粘贴代码]
### 选填项
- 测试框架：【Jest/Vitest/Pytest/JUnit?】（默认：自动检测）
- 测试风格：【BDD describe/it 风格?】
## 输出规范
使用 AAA 模式（Arrange-Act-Assert），覆盖：
1. **正常流程**（Happy Path）
2. **边界条件**（空值、极值、临界点）
3. **异常情况**（错误输入、异常抛出）
4. **异步操作**（如有 Promise/async）
每个测试用例包含：
- 清晰的命名（描述测试意图）
- 必要的注释（说明测试场景）
## 约束条件
- ✅ 测试用例命名要清晰表达测试意图
- ✅ 覆盖主要边界条件
- ✅ 测试代码要可直接运行
- ❌ 避免测试实现细节
- ❌ 避免测试用例之间有依赖🔧 重构建议
预期效果：给出安全的重构方案，降低改动风险
## 角色
你是重构专家，擅长识别代码坏味道并给出安全的重构方案。
## 任务
分析代码问题，给出安全的重构步骤和建议。
## 输入信息
### 必填项
- 代码：@【文件路径】 或 [粘贴代码]
### 选填项
- 已知问题：【你发现的问题?】
- 重构目标：【想达成什么效果?】
## 输出规范
1. **当前问题分析**
- 发现的坏味道（函数过长/参数过多/嵌套过深/重复代码/命名不清）
- 每个问题的严重程度（高/中/低）
2. **推荐的重构步骤**（按顺序）
- 每步做什么
- 每步的风险评估
- 如何验证这步成功
3. **需要补充的测试**
- 重构前应该有的测试
- 重构后需要新增的测试
4. **重构后的预期效果**
- 代码质量提升点
- 可维护性改进
## 约束条件
- ✅ 小步重构，每步可验证
- ✅ 保持对外接口不变
- ✅ 先有测试再重构
- ❌ 避免一次改动太多
- ❌ 避免改变业务逻辑检查点 ✅
全部通过才能继续
- [ ] 用 AI 识别了代码坏味道
- [ ] 生成了单元测试
- [ ] 完成了安全重构
- [ ] 测试全部通过
踩坑提醒
| 现象 | 原因 | 解决 |
|---|---|---|
| 重构后功能坏了 | 没先写测试 | 先生成测试再重构 |
| 测试覆盖率低 | 只测正常情况 | 补充边界条件和异常测试 |
| 坏味道识别不准 | 代码片段太小 | 给 AI 完整的文件上下文 |
本课小结
你学会了：
- 用 AI 识别代码坏味道
- 先写测试再重构的安全流程
- 自动生成单元测试
- 分析和补充边界测试
下一课预告
下一课我们将学习文档自动化和 Git 协作技巧。
📚 更多完整模板：Prompt 模板库