3、评审流程：计划阶段、准备阶段、评审会议、跟踪阶段
软件架构评审这件事，我做了十几年。说实话，很多团队把评审搞成了「走过场」——大家坐在一起，翻翻PPT，说几句「没问题」，然后就散了。结果呢？架构隐患一直埋到集成测试才爆发。
为什么会这样？因为评审流程没走对。今天我就把四个核心阶段掰开揉碎讲清楚。你想想看，一个完整的架构评审，其实就像一次「手术」——术前准备、术中操作、术后跟踪，哪个环节都不能少。
3.1 计划阶段：不打无准备之仗
我个人习惯，在评审开始前至少一周就要启动计划。这个阶段的核心就三件事：定目标、定人、定时间。
核心要点：计划阶段不是发个会议邀请就完事了。你得想清楚「为什么要评」和「评什么」。
3.1.1 明确评审目标
我在项目中遇到过一种情况：评审会开了两个小时，最后大家发现评审的目标都没对齐。有人以为是看功能完整性，有人以为是看性能指标，还有人以为是看代码规范……嗯，这就尴尬了。
所以，计划阶段第一件事就是明确评审目标。常见的架构评审目标包括：
- 合规性检查：架构是否满足ASPICE、ISO 26262等标准要求
- 技术可行性：架构方案在技术上是否可行，有没有重大风险
- 一致性验证：架构是否与系统需求、安全需求保持一致
- 可维护性评估：架构是否便于后续扩展和维护
3.1.2 确定评审范围
说白了，你不能什么都评。一次评审聚焦一个核心议题，效果最好。比如这次专门评「通信架构」，下次评「安全机制」。
| 评审类型 | 典型范围 | 建议时长 |
|---|---|---|
| 完整架构评审 | 所有架构视图、接口定义、部署方案 | 2-3天 |
| 专题评审 | 如：安全架构、通信架构、诊断架构 | 半天-1天 |
| 变更评审 | 仅涉及变更的部分及其影响范围 | 1-2小时 |
3.1.3 组建评审团队
我曾经犯过一个错误：评审团队全是自己项目组的人。结果呢？大家都太熟了，不好意思提反对意见。后来我学乖了，一定要拉几个「外人」进来——其他项目的架构师、功能安全工程师、测试负责人。
我的建议：评审团队至少包含三类角色——架构师（输出方）、评审专家（评估方）、记录员（中立方）。记录员这个角色很多人会忽略，但非常重要。没有记录，评审结论就是空话。
3.2 准备阶段：评审质量的关键
这个阶段，我把它叫做「评审的命门」。为什么这么说？因为评审会议的质量，80%取决于准备阶段做得好不好。
3.2.1 材料准备
评审材料不是越多越好。我见过有人把200页的设计文档扔给评审专家，说「你们先看看」。结果呢？没人看得完。
我的做法是：
- 核心材料：架构概览图（1页）、关键决策记录（3-5页）、接口定义（10页以内）
- 参考材料：详细设计文档、需求规格、安全分析报告（作为附件提供）
- 评审检查单：这个最重要！列出所有需要确认的条目
注意：评审材料必须在评审会议前至少3个工作日发出。我曾经有一次只提前1天发材料，结果评审专家根本没时间看，会议变成了「现场读文档」，浪费了所有人的时间。
3.2.2 预审环节
我个人习惯，在正式评审会议之前，先做一轮「预审」。说白了，就是找一两个资深专家，私下先过一遍。这样做的目的是：
- 提前发现明显的问题，避免在正式会议上浪费时间
- 让专家提前熟悉材料，正式会议时能直奔主题
- 收集初步意见，判断评审的「火药味」有多浓
3.2.3 评审检查单
嗯，这里要重点说说检查单。我这些年积累了一份「架构评审检查单」，每次评审前都会根据项目特点做调整。举个例子：
// 架构评审检查单（节选）
// 1. 架构完整性
// - [ ] 所有功能需求是否都有对应的架构元素？
// - [ ] 架构是否覆盖了所有运行模式（正常、降级、故障）？
// - [ ] 接口定义是否完整（包括信号类型、周期、超时处理）？
// 2. 安全相关
// - [ ] ASIL等级分配是否合理？
// - [ ] 安全机制是否在架构层面有体现？
// - [ ] 故障传播路径是否已识别？
// 3. 非功能需求
// - [ ] 实时性要求是否满足？
// - [ ] 资源预算（CPU、内存、带宽）是否合理？
// - [ ] 可扩展性是否考虑？
3.3 评审会议：高效推进的艺术
评审会议不是「学术研讨会」，更不是「批斗会」。它的核心目标是：达成共识、识别风险、做出决策。
3.3.1 会议节奏控制
我建议的会议节奏是这样的：
- 开场（10分钟）：主持人说明评审目标、议程、时间安排
- 架构介绍（30-45分钟）：架构师讲解核心设计思路和关键决策
- 逐项评审（60-90分钟）：按检查单逐项过，重点讨论分歧点
- 总结与决策（15分钟）：明确评审结论、待办事项、责任人
关键提醒：评审会议最怕「跑题」。我见过一个评审会，本来要评通信架构，结果讨论了一个小时「用哪个版本的编译器」……嗯，这时候主持人必须果断拉回来。
3.3.2 评审结论分类
评审结论不能模棱两可。我习惯用三种结论：
| 结论 | 含义 | 后续动作 |
|---|---|---|
| 通过 | 架构方案满足要求，无重大缺陷 | 进入下一阶段 |
| 有条件通过 | 存在少量问题，但可在后续修复 | 明确整改项和截止日期 |
| 不通过 | 存在重大缺陷，需要重新设计 | 重新组织评审 |
3.4 跟踪阶段：闭环才是终点
很多团队评审完了就完了，没人跟进整改。这是最大的浪费。我曾经在一个项目里，评审发现了12个问题，三个月后回头看，还有8个没改……
3.4.1 问题跟踪机制
我的做法是：评审结束后24小时内，发出正式的评审报告。报告里必须包含：
- 评审结论（通过/有条件通过/不通过）
- 所有发现的问题清单（编号、描述、严重等级）
- 每个问题的责任人、整改方案、截止日期
- 下次跟踪评审的时间
3.4.2 整改验证
整改不是「改完了就行」，必须验证。我习惯的做法是：
- 低严重等级问题：由架构师自行验证，在下次评审时汇报
- 中严重等级问题：由评审组长验证，出具验证报告
- 高严重等级问题：必须重新召开评审会议，由原评审团队确认
一个小技巧：我每次评审都会建一个「评审问题跟踪表」，用Excel或者JIRA都行。关键是要定期（比如每周）更新状态，直到所有问题关闭。你想想看，如果评审发现的问题都不了了之，那评审还有什么意义？
3.4.3 经验沉淀
最后一步，也是很多人忽略的一步——把评审中发现的问题和经验，沉淀到组织的知识库中。比如：
- 更新架构设计指南
- 完善评审检查单
- 形成典型问题案例库
我曾经参与过一个项目，连续三次评审都发现了「接口信号周期定义不一致」的问题。后来我们把这个问题加到了检查单里，再也没出现过。这就是经验沉淀的价值。
避坑指南：我曾经犯过一个错误——评审跟踪阶段只关注「改没改」，不关注「改得好不好」。结果有一次，开发人员为了赶进度，把架构问题「绕过去」了，表面上问题关闭了，实际上埋了更大的坑。所以，跟踪阶段一定要看整改方案的质量，不能只看「是否完成」。
好了，评审流程的四个阶段就讲到这里。说白了，计划阶段是「定调子」，准备阶段是「打基础」，评审会议是「做决策」，跟踪阶段是「保落地」。四个阶段环环相扣，缺一不可。下次你做架构评审的时候，不妨对照这个流程走一遍，我保证效果不一样。