📚 课程目录第2章评审标准分类

2. 评审标准分类：技术评审、管理评审、文档评审、代码评审

评审标准是衡量交付物是否达成预期质量、完整性与合规性的基准线。根据评审对象与关注维度的不同，可将评审活动划分为四大类：技术评审、管理评审、文档评审与代码评审。每类评审的目标、参与角色、检查重点与产出物均有显著差异，在版本规划中需分别设定评审节点。

  关键认知：四类评审并非固定孤立，复杂变更往往需要技术+文档或管理+代码的联合评审。版本规划节点需根据实际交付物组合选择对应的评审类型。

维度	内容说明
适用场景	需求分析阶段、概要/详细设计、架构变更、接口变更、安全方案设计
前置条件	设计文档（含架构图、交互图、数据流图）已定稿并提前48小时分发至评审组
操作步骤	主持人介绍评审目标与范围（5min）作者按模块逐段讲解设计思路（15-30min）评审人依次提问，作者应答并记录待办项汇总缺陷/风险清单并投票决定是否通过若未通过则制定二次评审计划
输入/输出物	输入：设计文档、需求规格、已知约束说明输出：技术评审报告（含缺陷清单、风险评估、建议改进项）
责任边界	作者：提交设计与问题回复；评审组：判断设计可行性；评审主持人：控制节奏与结论
记录材料	技术评审记录表（含评审项、结论、待办项、责任人、截止日期）
异常处理	若关键缺陷数 > 3 或架构出现重大分歧，立即中止评审，更新设计后重新发起
验收标准	所有已识别缺陷均已确认解决方案或已关闭，评审报告签署通过

维度	内容说明
适用场景	里程碑节点、版本迭代结束、项目周/月度复盘、重大风险事件触发时
前置条件	项目周报/月报、燃尽图、资源利用率统计、风险登记册最新版本
操作步骤	项目经理展示进度与偏差分析（10min）核心成员汇报关键风险与缓解措施（10min）管理层确认资源调整与优先级变更更新项目计划并签署管理评审纪要
输入/输出物	输入：进度报告、缺陷趋势、资源台账输出：管理评审纪要（含变更决议、风险更新、下阶段目标）
责任边界	PM：汇报与提议；管理层：做决策与资源承诺；QA：监督过程一致性
记录材料	管理评审签到表、决策追踪表
异常处理	若进度偏差 > 20% 或关键路径受阻，须立即触发专题会议并上报项目指导委员会
验收标准	管理评审纪要已审批，变更项已录入项目计划系统

维度	内容说明
适用场景	需求文档冻结、用户手册终稿、接口规范发布前、测试用例评审前
前置条件	文档通过自检清单、模板合规性检查，作者已排除拼写与格式低级错误
操作步骤	主持人宣读文档评审范围与检查项分类评审人逐页核查文档结构与逻辑（可并行离线评审）汇总书面意见，标记必须修改项作者确认修改计划与时间点评审人确认最终版本并签署
输入/输出物	输入：待评审文档（含版本号、变更历史）、文档检查单输出：文档评审意见表、签批版文档
责任边界	文档主编：内容正确性；评审人：完整性、一致性与可读性判断
记录材料	文档评审问题清单、文档签审表
异常处理	若发现10%以上内容与原有设计不符，退回重新撰写后再评
验收标准	所有“必须修改”项已闭环，文档版本号更新且归档至受控库

维度	内容说明
适用场景	合入主干/Release分支前、重构后、Fix提交、新功能合并请求时
前置条件	代码已通过静态检查（Lint/ESLint/Pylint）、单元测试覆盖率不低于80%
操作步骤	提交者发起Merge/Pull Request并附变更说明评审人逐行审查代码变更（diff），关注逻辑、安全与风格提交者在评审注释中回复修改方案所有Approval评论解决后，由评审人点击确认合并代码并清理Review分支
输入/输出物	输入：代码变更集（commit范围）、关联工单输出：Code Review记录（含评论、修改提交记录、CI通过结果）
责任边界	作者：保证代码可读与自测；Reviewer：发现潜在缺陷；Maintainer：最终合并决策
记录材料	CR平台（如GitLab/GitHub/Phabricator）自动记录全部交互与决议
异常处理	若发现严重安全漏洞或API破坏性变更，立即暂停合入并升级至技术评审
验收标准	至少1位评审人Approved，所有Comments已Resolved，CI Pipeline通过

版本规划小贴士：在版本规划节点设计时，建议将技术评审和代码评审作为强制门禁，管理评审作为阶段检查点，文档评审作为发布前的质量保障环节。四者共同构成完整的评审质量网。

常见误区：将代码评审当作技术评审的简化版，直接在CR中讨论架构问题；或将管理评审当作技术决策会。两种混淆都会导致评审效率降低和决策质量下降。