设计评审规范

设计评审流程、准入退出条件

评审准入条件

规则：设计评审前必须满足准入条件，条件不满足不得召开评审会议，避免无效评审。

[Requirement] 评审材料须至少提前 1 个工作日发出，所有参会人须会前阅读。

[Requirement] 方案文档须使用统一模板（见技术方案设计规范），章节齐全，无空内容。

[Requirement] 方案须包含：背景目标、架构设计、接口设计、数据模型、非功能需求、风险评估。

[Standard] 评审须明确评审范围（本次评审覆盖哪些模块/接口），范围外的内容不评审。

[Standard] 参会人须包含：方案作者、模块负责人、架构师/资深研发、测试代表；涉及安全的须有安全代表。

准入检查清单：

检查项	要求	不满足时
方案文档	模板章节齐全，内容完整	退回补充
评审材料	提前 ≥1 工作日发出	改期
评审范围	明确覆盖范围	会中确认范围
参会人	产品/研发/测试三方齐全	改期
关联需求	关联需求 ID 与验收标准	退回补充

[Caution] 准入条件不满足强行开会，评审会将沦为”方案宣讲会”，无法产生有效决策。

反模式：

❌ 评审当天才发方案，参会人现场第一次看。
❌ 方案文档只有架构图，没有接口和数据设计。
❌ 测试和安全缺席评审，上线前才发现问题。

评审流程

规则：设计评审须按标准流程进行，确保评审充分、结论明确、可追溯。

[Requirement] 评审会议时长控制在 60 分钟内，超时须拆分多次评审。

[Requirement] 评审结论必须为：通过 / 有条件通过 / 打回，不允许模糊结论。

[Standard] 评审流程：会前阅读 → 会中讨论 → 结论确认 → 记录归档。

[Standard] 会中讨论按”架构 → 接口 → 数据 → 非功能 → 风险”顺序进行，避免跳跃。

[Default] 默认评审会议 60 分钟，方案复杂度高可申请 90 分钟。

评审流程：

1. 会前（T-1 工作日）
   ├─ 方案作者发出评审材料
   └─ 参会人阅读并预提问题

2. 会中（60 分钟）
   ├─ 5 分钟：方案作者概述背景与目标
   ├─ 10 分钟：架构设计讲解
   ├─ 15 分钟：接口与数据设计讨论
   ├─ 10 分钟：非功能需求与风险讨论
   ├─ 15 分钟：问题讨论与决议
   └─ 5 分钟：结论确认

3. 会后（1 工作日内）
   ├─ 方案作者整理评审记录
   ├─ 修改项责任人确认
   └─ 记录归档至方案文档

评审角色与职责：

角色	职责
方案作者	讲解方案、回答问题、记录评审意见
架构师	把控架构合理性、技术选型、非功能需求
模块负责人	评估对现有模块的影响、可行性
测试代表	评估可测试性、验收标准覆盖度
安全代表（如涉及）	评估安全风险、合规要求
主持人	控制时间、确保讨论聚焦、推动结论

反模式：

❌ 评审会变成方案作者的独角戏，其他人不发言。
❌ 讨论发散，从架构扯到具体代码实现，超时严重。
❌ 评审没有结论，会后”凭印象”开发。

评审要点

规则：设计评审须覆盖以下要点，确保方案的完整性、正确性、可行性和可维护性。

[Requirement] 评审须覆盖：需求一致性、架构合理性、接口设计、数据模型、非功能需求、风险与依赖。

[Standard] 每个要点须有明确的通过标准，不满足须记录为修改项。

[Suggestion] 使用评审检查清单逐项确认，避免遗漏。

评审检查清单：

1. 需求一致性

检查项	通过标准
方案与需求对齐	方案覆盖需求的所有功能点，无遗漏
验收标准可实现	每条 AC 都有对应的技术实现路径
范围边界清晰	明确本次做什么、不做什么

2. 架构合理性

检查项	通过标准
模块划分	按业务领域划分，职责单一，边界清晰
依赖关系	依赖单向、无循环依赖
扩展性	新增功能可通过扩展实现，无需大规模修改
复杂度	方案复杂度与需求规模匹配，无过度设计

3. 接口设计

检查项	通过标准
接口契约完整	入参、出参、异常定义明确
向后兼容	接口变更不破坏已有调用方
幂等性	写操作有幂等设计
错误处理	错误码定义清晰，异常场景有处理

4. 数据模型

检查项	通过标准
表结构设计	字段类型合理，主键/索引设计恰当
数据一致性	明确一致性要求（强一致/最终一致）
数据迁移	存量数据迁移方案可行
性能	预估数据量下查询性能达标

5. 非功能需求

检查项	通过标准
性能	响应时间、并发量有量化指标与验证方案
可用性	可用性目标、故障恢复方案明确
安全性	鉴权、加密、敏感数据处理有设计
可观测性	日志、监控、告警设计齐全

6. 风险与依赖

检查项	通过标准
风险识别	高风险项有缓解措施与负责人
外部依赖	依赖项明确，有降级/兜底方案
排期可行	任务拆分合理，估算可信

反模式：

❌ 评审只看架构图，不看接口和数据设计。
❌ 只讨论功能，忽略非功能需求和风险。
❌ 评审时不对照验收标准，导致开发完无法验收。

退出条件

规则：设计评审须满足退出条件方可结束，未满足退出条件的评审不得视为通过。

[Requirement] 评审结论必须明确（通过/有条件通过/打回），并有所有关键参会人确认。

[Requirement] “有条件通过”的修改项须有明确的负责人和截止时间。

[Standard] “通过”条件：无高优先级修改项，所有中低优先级修改项有明确处理计划。

[Standard] “有条件通过”条件：存在中优先级修改项，但不影响整体方案方向，修改项须在开发启动前完成。

[Standard] “打回”条件：存在高优先级问题（架构不合理、需求理解偏差、关键风险无应对），须修改后重新评审。

退出条件矩阵：

结论	高优先级问题	中优先级问题	低优先级问题	后续动作
通过	0	0-N（有计划）	0-N	直接开发
有条件通过	0	≥1（有负责人+截止时间）	0-N	完成修改项后开发
打回	≥1	任意	任意	修改后重新评审

问题优先级定义：

优先级	定义	示例
高	影响方案正确性或可行性，不解决无法开发	架构理解错误、关键接口缺失、数据一致性无方案
中	影响质量但不影响方向，可在开发前修复	非功能指标缺失、错误码不统一、索引设计不合理
低	优化建议，不影响开发	命名优化、注释补充、文档格式调整

反模式：

❌ 评审结论”原则通过，但有些地方需要改”——没有明确哪些要改、谁改、什么时候改完。
❌ 高优先级问题存在却给”通过”，开发中才发现方案走不通。
❌ “有条件通过”的修改项没有截止时间，无限拖延。

评审记录

规则：评审记录是评审的正式产出，须完整、准确、可追溯，归档至方案文档。

[Requirement] 评审记录须在评审会后 1 个工作日内完成，并归档至方案文档末尾。

[Requirement] 评审记录须包含：评审时间、参会人、结论、修改项（含优先级/负责人/截止时间）。

[Standard] 修改项须标注优先级（高/中/低），并明确验证方式（review 确认/测试验证）。

[Standard] “有条件通过”的修改项完成后，须由架构师或模块负责人确认，确认后方案正式生效。

[Default] 评审记录使用 Markdown 格式，追加到方案文档末尾的”评审记录”章节。

评审记录模板：

## 评审记录
 
### 第一次评审（2024-10-14）
 
**参会人**：张三（作者）、李四（架构师）、王五（模块负责人）、赵六（测试）
 
**结论**：有条件通过
 
**修改项**：
 
| 编号 | 优先级 | 修改内容 | 负责人 | 截止时间 | 验证方式 |
|------|--------|----------|--------|----------|----------|
| M1 | 高 | 补充支付失败的重试与兜底机制设计 | 张三 | 2024-10-15 | 李四 review 确认 |
| M2 | 中 | 数据库索引需覆盖按订单号查询场景 | 张三 | 2024-10-15 | 王五 review 确认 |
| M3 | 低 | 接口错误码与全局错误码规范对齐 | 张三 | 2024-10-16 | 李四 review 确认 |
 
**修改项完成确认**：
- [x] M1 已完成，李四 2024-10-15 确认
- [x] M2 已完成，王五 2024-10-15 确认
- [x] M3 已完成，李四 2024-10-16 确认
- 方案正式生效时间：2024-10-16

评审记录检查清单：

检查项	要求
评审时间	明确到日期
参会人	列出所有参会人及角色
结论	通过/有条件通过/打回
修改项	每项含编号、优先级、内容、负责人、截止时间、验证方式
确认记录	修改项完成后有确认人和时间

反模式：

❌ 评审没有记录，会后无人记得讨论了什么。
❌ 修改项没有负责人和截止时间，不了了之。
❌ “有条件通过”的修改项完成后无人确认，方案是否生效不明确。