code-review

name	code-review
description	代码审查工作流。对照需求和开发计划检查代码，确保功能完整、代码规范、无技术债。在"/review"、"/代码审查"、"review代码"时使用。

代码审查工作流

定位

开发流程第四阶段：代码 Review

核心目标：确保功能完整、代码规范、无技术债

前置条件

• 需求文档已存在：docs/requirements/feature-xxx.md
• 开发计划已存在：docs/dev-plans/feature-xxx.md
• 开发计划中所有任务标记为"已完成"

工作流程

1. 准备阶段

读取相关文档：

• 需求文档：了解要实现什么
• 开发计划：了解怎么实现的
• 代码变更：git diff 或查看修改的文件

建立检查清单：

• 从需求文档提取功能列表
• 从开发计划提取任务列表
• 从代码规范提取检查项

2. 功能完整性检查

对照需求文档：

• 每个功能点是否都已实现？
• 验收标准是否都能满足？
• 边界情况是否都已处理？

对照开发计划：

• 每个任务是否都已完成？
• 涉及的文件是否都已修改？
• 是否有遗漏的任务？

3. 代码规范检查

命名规范：

• 变量/函数/类命名是否清晰？
• 是否符合项目命名约定？

代码结构：

• 函数是否过长？（建议 < 50 行）
• 是否有重复代码？
• 模块划分是否合理？

注释和文档：

• 复杂逻辑是否有注释？
• 公共 API 是否有文档？

错误处理：

• 异常是否正确捕获和处理？
• 错误信息是否清晰？

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
• 🟡 中：代码规范问题、轻微技术债
• 🟢 低：建议性改进、代码风格

流转条件

进入下一阶段（问题修复）：

• Review 报告生成
• 存在待修复问题

跳过修复阶段（直接进入测试）：

• Review 报告状态为"已通过"
• 无待修复问题

注意事项

1. 客观公正：基于事实，不带个人偏好
2. 具体可行：问题描述要具体，建议要可执行
3. 优先级清晰：严重问题优先处理
4. 不吹毛求疵：关注重要问题，不纠结细枝末节
5. 建设性反馈：指出问题的同时给出解决方案