# 缺陷预防评审检查清单

## 一、需求评审检查清单

### 1.1 逆向操作场景
- [ ] 是否考虑了用户修改前置操作后的系统行为？
- [ ] 级联依赖关系是否完整定义？（如省市区联动）
- [ ] 状态回退场景是否有明确的处理规则？
- [ ] 用户操作路径是否覆盖正向和逆向流程？

### 1.2 依赖踏空场景
- [ ] 是否识别了所有强依赖关系？
- [ ] 依赖数据删除/变更后的处理策略是否明确？
- [ ] 历史数据的保护机制是否定义？
- [ ] 降级方案是否可行且用户体验可接受？

### 1.3 并发操作场景
- [ ] 多端操作同一资源的冲突解决机制是否定义？
- [ ] 多用户并发修改的数据一致性方案是否明确？
- [ ] 实时同步的频率和延迟要求是否合理？
- [ ] 是否需要支持离线操作和后续同步？

### 1.4 新旧交替场景
- [ ] 版本升级策略是否明确（停服 vs 不停服）？
- [ ] 数据迁移方案是否评估（迁移脚本 vs 应用适配）？
- [ ] 历史数据的兼容性访问方案是否定义？
- [ ] 回滚方案是否可行？

### 1.5 状态迁移场景
- [ ] 是否定义了完整的状态流转图？
- [ ] 是否存在非法状态跳转的可能？
- [ ] 状态回退/撤销是否有明确规则？
- [ ] 终态（如已完成/已取消）是否允许变更？

### 1.6 因果判定场景
- [ ] 复杂业务规则是否梳理了所有条件组合？
- [ ] 规则冲突时的优先级是否明确？
- [ ] 是否遗漏了某些条件组合？
- [ ] 是否用判定表或决策树梳理业务规则？

### 1.7 需求完整性
- [ ] 边界条件是否明确？（空值、最大值、最小值）
- [ ] 异常场景是否定义？（网络异常、数据异常）
- [ ] 性能要求是否量化？（响应时间、并发量）
- [ ] 安全要求是否考虑？（权限、敏感数据）

---

## 二、研发设计评审检查清单

### 2.1 架构设计
- [ ] 是否采用合理的分层架构？
- [ ] 服务拆分边界是否清晰？
- [ ] 数据流向和调用链路是否完整？
- [ ] 是否考虑了水平扩展能力？

### 2.2 数据一致性
- [ ] 并发控制的实现方案？（乐观锁、悲观锁、分布式锁）
- [ ] 事务边界是否合理？
- [ ] 分布式事务的处理方案？
- [ ] 最终一致性的补偿机制？

### 2.3 依赖管理
- [ ] 依赖关系的校验机制？
- [ ] 循环依赖是否避免？
- [ ] 依赖变更的兼容性处理？
- [ ] 依赖消失的降级策略？

### 2.4 版本兼容
- [ ] 数据结构变更的兼容方案？
- [ ] API版本管理策略？
- [ ] 新旧数据共存的适配层设计？
- [ ] 废弃字段/接口的清理计划？

### 2.5 状态管理
- [ ] 状态流转是否用状态机控制？
- [ ] 状态校验逻辑是否集中管理？
- [ ] 是否存在绕过状态校验的接口？
- [ ] 状态变更是否记录审计日志？

### 2.6 业务规则
- [ ] 复杂规则是否用判定表梳理？
- [ ] 条件组合是否覆盖完全？
- [ ] 规则冲突时的优先级是否明确？
- [ ] 规则变更是否影响现有数据？

### 2.7 性能设计
- [ ] 数据库索引设计是否合理？
- [ ] 缓存策略是否定义？（缓存什么、何时失效）
- [ ] 大数据量的分页方案？
- [ ] 慢查询的预防机制？

### 2.8 安全设计
- [ ] 权限控制粒度是否足够？
- [ ] 敏感数据是否加密存储？
- [ ] SQL注入、XSS等常见漏洞的防护？
- [ ] 接口防重放、防刷机制？

---

## 三、测试用例评审检查清单

### 3.1 测试覆盖度
- [ ] 是否覆盖所有核心功能路径？
- [ ] 边界条件测试是否完整？
- [ ] 异常场景测试是否充分？
- [ ] 逆向操作场景是否覆盖？

### 3.2 缺陷预防场景
- [ ] 依赖踏空场景测试用例？
- [ ] 同屏并发场景测试用例？
- [ ] 新旧数据兼容测试用例？
- [ ] 数据迁移验证测试用例？
- [ ] 状态流转路径测试用例？
- [ ] 条件组合场景测试用例？

### 3.3 测试数据
- [ ] 测试数据是否覆盖各种边界值？
- [ ] 是否有足够的异常数据？
- [ ] 测试数据的准备和清理方案？
- [ ] 是否考虑了数据量对性能的影响？

### 3.4 测试环境
- [ ] 测试环境是否与生产环境一致？
- [ ] 多端测试设备是否准备齐全？
- [ ] 并发测试的压力工具是否准备？
- [ ] 监控和日志是否完善？

### 3.5 验收标准
- [ ] 通过标准是否明确？
- [ ] 性能指标是否量化？
- [ ] 缺陷严重程度的分级标准？
- [ ] 遗留问题的处理方案？

---

## 四、代码评审检查清单

### 4.1 功能正确性
- [ ] 业务逻辑是否正确实现？
- [ ] 边界条件是否正确处理？
- [ ] 异常场景是否有容错处理？
- [ ] 是否覆盖了所有需求场景？

### 4.2 逆向操作处理
- [ ] 前置操作改变后，后续操作是否正确处理？
- [ ] 级联依赖关系的联动更新是否正确？
- [ ] 状态回退后的数据一致性是否保证？

### 4.3 依赖踏空处理
- [ ] 依赖数据不存在时是否有异常处理？
- [ ] 依赖关系变更时是否有校验逻辑？
- [ ] 历史数据的访问是否有兼容性处理？
- [ ] 是否有适当的用户提示？

### 4.4 状态迁移处理
- [ ] 状态变更是否有统一的状态机控制？
- [ ] 非法状态跳转是否有拦截逻辑？
- [ ] 状态回退逻辑是否正确实现？
- [ ] 终态是否禁止变更？

### 4.5 因果判定处理
- [ ] 多重条件判断是否有遗漏的分支？
- [ ] if-else 嵌套是否过深？是否可用策略模式简化？
- [ ] 条件组合的覆盖是否完整？

### 4.6 并发安全
- [ ] 共享资源的访问是否线程安全？
- [ ] 数据库操作是否有并发控制？
- [ ] 缓存更新是否有竞争条件？
- [ ] 分布式环境下的一致性如何保证？

### 4.7 代码质量
- [ ] 函数长度是否合理？（建议<50行）
- [ ] 圈复杂度是否过高？（建议<10）
- [ ] 是否有重复代码？
- [ ] 命名是否清晰易懂？
- [ ] 注释是否充分且准确？

### 4.8 性能优化
- [ ] 是否有N+1查询问题？
- [ ] 循环中是否有数据库查询？
- [ ] 大对象的处理是否合理？
- [ ] 是否有内存泄漏风险？

### 4.9 安全风险
- [ ] 是否有SQL注入风险？
- [ ] 是否有XSS漏洞？
- [ ] 敏感信息是否泄露？
- [ ] 权限校验是否完整？

### 4.10 可维护性
- [ ] 代码是否易于理解？
- [ ] 修改一处是否影响其他功能？
- [ ] 是否有足够的单元测试？
- [ ] 错误日志是否有助于排查问题？

---

## 五、评审流程建议

### 5.1 评审准备
1. 提前1天发送评审材料
2. 评审人员提前阅读并标注问题
3. 准备评审会议议程和时间安排

### 5.2 评审会议
1. 作者讲解设计思路和关键决策（15分钟）
2. 评审人员逐一提出问题和建议（30分钟）
3. 讨论并达成共识（15分钟）
4. 明确待办事项和责任人（10分钟）

### 5.3 评审后续
1. 24小时内整理评审记录
2. 作者根据评审意见修改
3. 重要修改需要二次评审
4. 跟踪待办事项的完成情况

### 5.4 评审度量
- 评审覆盖率 = 已评审文档数 / 总文档数
- 缺陷发现率 = 评审发现的缺陷数 / 评审时长
- 评审通过率 = 一次通过评审的文档数 / 总评审数
- 评审有效性 = 评审发现的缺陷数 / 总缺陷数

---

## 六、缺陷成本分析

### 6.1 不同阶段修复缺陷的成本

| 阶段 | 相对成本 | 示例 |
|------|---------|------|
| 需求阶段 | 1x | 需求评审发现逻辑漏洞 |
| 设计阶段 | 3-5x | 设计评审发现架构问题 |
| 编码阶段 | 10x | 代码评审发现逻辑错误 |
| 测试阶段 | 20-50x | 测试发现功能缺陷 |
| 生产环境 | 100-1000x | 线上故障紧急修复 |

### 6.2 缺陷预防的价值

- **提前发现**：需求阶段发现1个缺陷 = 节省测试阶段10-50个缺陷的修复成本
- **质量提升**：系统化评审可减少30-50%的缺陷逃逸率
- **效率提升**：早期发现问题，避免返工，缩短开发周期
- **团队成长**：通过评审过程，团队成员互相学习，提升整体能力

---

## 使用建议

### 如何使用本检查清单

1. **选择合适的清单**：根据评审类型选择对应的检查清单
2. **灵活裁剪**：根据项目实际情况增减检查项
3. **持续完善**：将项目中发现的问题补充到清单中
4. **自动化辅助**：将可自动化的检查项集成到CI/CD流程

### 评审会议的最佳实践

- 控制会议时间在1小时内
- 关注问题而非指责个人
- 记录所有发现的问题和建议
- 明确优先级和责任人
- 跟踪问题的解决进度

### 缺陷预防的文化建设

- 将评审纳入团队的标准流程
- 奖励主动发现问题的行为
- 定期分享缺陷预防的案例
- 建立缺陷知识库，持续积累