# 代码审查规则

## 你必须审查的方面

### 1. 功能正确性（必须验证）

**检查项：**

- [ ] 代码是否实现了预期的功能？
- [ ] 是否处理了所有边界情况？
- [ ] 是否处理了所有异常情况？
- [ ] 是否有潜在的安全漏洞？
- [ ] 是否有明显的逻辑错误？

**行动要求：**

- 如果发现功能未实现或实现错误，必须指出并要求修复
- 如果发现缺少边界或异常处理，必须要求补充
- 如果发现安全漏洞，必须标记为阻塞性问题

### 2. 代码质量（必须评估）

**检查项：**

- [ ] 代码是否清晰、易读？
- [ ] 变量和函数命名是否准确、有意义？
- [ ] 是否有重复代码需要重构？
- [ ] 代码结构是否合理？

**行动要求：**

- 如果命名不清晰，必须建议更清晰的命名
- 如果发现重复代码，必须建议提取公共逻辑
- 如果代码结构混乱，必须建议重构

### 3. 性能考虑（必须评估）

**检查项：**

- [ ] 是否存在明显的性能瓶颈？
- [ ] 算法和数据结构选择是否合理？
- [ ] 是否有不必要的计算或资源消耗？
- [ ] 是否有内存泄漏风险？

**行动要求：**

- 如果发现性能问题，必须指出并提供优化建议
- 如果算法选择不当，必须建议更合适的方案

### 4. 可维护性（必须评估）

**检查项：**

- [ ] 代码结构是否合理？
- [ ] 是否遵循项目的编码规范？
- [ ] 是否有适当的注释和文档？
- [ ] 代码是否易于理解和修改？

**行动要求：**

- 如果违反编码规范，必须要求修正
- 如果缺少必要注释，必须要求补充
- 如果代码难以理解，必须要求重构

## 审查行为规范

### 你必须遵守的原则

- **必须**：保持建设性的反馈，关注代码而非个人
- **必须**：提出具体、可操作的建议
- **必须**：认可好的实践和设计
- **必须**：及时响应审查请求
- **禁止**：使用攻击性或贬低性的语言

### 审查建议的格式

- 明确指出问题所在（文件、行号、代码片段）
- 说明问题的影响（为什么这是个问题）
- 提供具体的修复建议（如何修复）
- 如果是阻塞性问题，明确标记

### 复杂变更的处理

- 对于大型或复杂的变更，可以要求分阶段审查
- 建议将复杂功能拆分为多个小的、可审查的提交

## 审查检查清单

在完成代码审查时，你必须确认：

**功能层面：**

- [ ] 代码实现了预期功能
- [ ] 处理了边界和异常情况
- [ ] 没有明显的 bug 或逻辑错误

**质量层面：**

- [ ] 代码符合项目的编码规范
- [ ] 命名清晰、有意义
- [ ] 没有重复代码
- [ ] 代码结构合理

**安全与性能：**

- [ ] 没有安全漏洞
- [ ] 性能可接受
- [ ] 资源使用合理

**可维护性：**

- [ ] 有适当的错误处理
- [ ] 有必要的测试覆盖
- [ ] 代码注释清晰、准确
- [ ] 代码易于理解和维护
