| name | code-review |
| description | 代码审查工作流。对照需求和开发计划检查代码,确保功能完整、代码规范、无技术债。在"/review"、"/代码审查"、"review代码"时使用。 |
代码审查工作流
定位
开发流程第四阶段:代码 Review
核心目标:确保功能完整、代码规范、无技术债
前置条件
- 需求文档已存在:
docs/requirements/feature-xxx.md
- 开发计划已存在:
docs/dev-plans/feature-xxx.md
- 开发计划中所有任务标记为"已完成"
工作流程
1. 准备阶段
读取相关文档:
- 需求文档:了解要实现什么
- 开发计划:了解怎么实现的
- 代码变更:git diff 或查看修改的文件
建立检查清单:
- 从需求文档提取功能列表
- 从开发计划提取任务列表
- 从代码规范提取检查项
2. 功能完整性检查
对照需求文档:
对照开发计划:
3. 代码规范检查
命名规范:
- 变量/函数/类命名是否清晰?
- 是否符合项目命名约定?
代码结构:
- 函数是否过长?(建议 < 50 行)
- 是否有重复代码?
- 模块划分是否合理?
注释和文档:
错误处理:
4. 技术债检查
临时方案:
- 是否有 TODO/FIXME 注释?
- 是否有硬编码的值?
- 是否有绕过正常流程的 hack?
性能问题:
- 是否有明显的性能瓶颈?
- 是否有不必要的重复计算?
- 数据库查询是否优化?
安全问题:
- 是否有 SQL 注入风险?
- 是否有 XSS 风险?
- 敏感信息是否正确处理?
5. 生成 Review 报告
保存到 docs/reviews/feature-xxx.md
交付物格式
# [Feature 名称] Review 报告
> Review 日期:YYYY-MM-DD
> 需求文档:[feature-xxx.md](../requirements/feature-xxx.md)
> 开发计划:[feature-xxx.md](../dev-plans/feature-xxx.md)
> 状态:待修复 / 已通过
## 总体评价
[一句话总结 Review 结果]
## 功能完整性
### 需求覆盖
| 功能 | 状态 | 备注 |
|-----|------|------|
| F1: xxx | ✅ 已实现 | - |
| F2: xxx | ⚠️ 部分实现 | 缺少 xxx |
| F3: xxx | ❌ 未实现 | - |
### 任务完成
| 任务 | 状态 | 备注 |
|-----|------|------|
| T1: xxx | ✅ 已完成 | - |
| T2: xxx | ✅ 已完成 | - |
## 代码规范
### 命名规范
- [x] 变量命名清晰
- [ ] 函数命名:`handleXxx` 建议改为 `onXxx`
### 代码结构
- [x] 函数长度合理
- [ ] 重复代码:`src/a.ts:20` 和 `src/b.ts:30` 逻辑重复
### 注释文档
- [x] 复杂逻辑有注释
- [ ] 公共 API 缺少 JSDoc
## 技术债
### 临时方案
| 位置 | 问题 | 建议 |
|-----|------|------|
| `src/xxx.ts:42` | TODO 注释未处理 | 实现或移除 |
| `src/yyy.ts:15` | 硬编码的 URL | 移到配置文件 |
### 性能问题
- 无明显性能问题
### 安全问题
- 无明显安全问题
## 问题清单
| ID | 严重程度 | 问题描述 | 位置 | 状态 |
|----|---------|---------|------|------|
| R1 | 🔴 高 | F2 功能未完整实现 | - | ⬜ 待修复 |
| R2 | 🟡 中 | 重复代码需要抽取 | src/a.ts:20 | ⬜ 待修复 |
| R3 | 🟢 低 | 建议添加 JSDoc | src/api.ts | ⬜ 待修复 |
## 修复建议
### R1: F2 功能未完整实现
**问题**:缺少 xxx 功能
**建议**:在 `src/xxx.ts` 中添加 xxx 逻辑
**参考**:需求文档 F2 描述
### R2: 重复代码需要抽取
**问题**:`src/a.ts:20` 和 `src/b.ts:30` 逻辑重复
**建议**:抽取为公共函数 `utils/xxx.ts`
## 修复记录
| ID | 修复时间 | Commit | 状态 |
|----|---------|--------|------|
| R1 | - | - | ⬜ 待修复 |
| R2 | - | - | ⬜ 待修复 |
严重程度定义
- 🔴 高:功能缺失、安全漏洞、严重 bug
- 🟡 中:代码规范问题、轻微技术债
- 🟢 低:建议性改进、代码风格
流转条件
进入下一阶段(问题修复):
跳过修复阶段(直接进入测试):
注意事项
- 客观公正:基于事实,不带个人偏好
- 具体可行:问题描述要具体,建议要可执行
- 优先级清晰:严重问题优先处理
- 不吹毛求疵:关注重要问题,不纠结细枝末节
- 建设性反馈:指出问题的同时给出解决方案