1. 架构评审概述：什么是架构评审、为什么需要架构评审、评审的时机与频率
1.1 什么是架构评审？
架构评审，说白了就是一群人坐在一起，对着你的软件架构图「找茬」。但这不是普通的找茬，而是有方法、有流程的集体智慧碰撞。
我个人习惯把架构评审比作「盖房子前的图纸会审」。你想想看，地基都打好了才发现承重墙位置不对，那代价可就大了。软件架构也一样——等代码都写完了再改架构，那叫重构，不叫评审。
具体来说，架构评审包含这几个核心要素：
- 评审对象：系统架构设计文档、组件图、时序图、部署视图等
- 评审人员：架构师、功能安全工程师、测试代表、项目负责人
- 评审目标：发现设计缺陷、验证非功能需求、确保一致性
- 评审输出：评审报告、问题清单、改进建议、决策记录
重要提醒：架构评审不是走过场，更不是「PPT汇报」。我在项目中遇到过有人把架构评审搞成了个人演讲，全程自嗨，结果评审完什么问题都没发现——那还不如不开。
1.2 为什么需要架构评审？
这个问题我问过很多刚入行的工程师。有人说是「流程要求」，有人说是「领导安排的」。嗯，这些都对，但没说到点子上。
我总结了三层原因：
第一层：发现「看不见的坑」
代码层面的问题，单元测试能发现。但架构层面的问题，比如模块间耦合度过高、依赖关系混乱、安全机制缺失——这些在代码层面很难看出来。架构评审就是专门抓这些「大问题」的。
我曾经在一个项目中，评审时发现某个关键安全模块的看门狗机制被设计成了「软件定时器轮询」。这要是上了车，万一主控芯片死机，看门狗也跟着失效——后果不堪设想。还好在评审阶段就发现了。
第二层：统一团队认知
你想想看，一个项目少则十几人，多则上百人。每个人对架构的理解可能都不一样。架构评审就是让大家「对齐」的过程。我记得有一次评审，架构师说「这里用发布订阅模式」，结果三个开发人员理解成了三种不同的实现方式。要不是评审时讨论清楚了，后面肯定要返工。
第三层：满足功能安全要求
做汽车软件的都知道，ISO 26262 明确要求对架构设计进行评审。这不是可选项，是强制项。而且评审的深度、广度、参与人员都有具体要求。说白了，这是合规性的硬门槛。
| ASIL等级 | 评审要求 | 独立评审要求 |
|---|---|---|
| ASIL A | 建议评审 | 无 |
| ASIL B | 必须评审 | 建议独立评审 |
| ASIL C/D | 必须评审 | 必须独立评审 |
小提示：独立评审不是说找个外人来，而是指评审人员不参与该模块的设计工作。比如A模块的架构师去评审B模块的设计，这就叫独立评审。
1.3 评审的时机与频率
这个问题很关键。评审早了，架构还没成型，评审没意义。评审晚了，改造成本太高。那什么时候最合适？
评审时机：三个关键节点
- 概念设计阶段：系统需求刚确定，架构方案初步形成。这时候评审重点是「方向对不对」。
- 详细设计阶段：架构已经细化到模块级别，接口定义基本完成。这时候评审重点是「细节是否合理」。
- 实现前最终评审：所有设计文档都完成了，准备开始编码。这时候评审重点是「有没有遗漏」。
我个人建议，至少要在「详细设计阶段」和「实现前」各做一次正式评审。概念阶段的评审可以灵活一些，用非正式的方式也行。
评审频率：不是越多越好
有人觉得评审次数越多越好，其实不然。评审太频繁，团队会疲劳，评审质量反而下降。我见过一个项目，每周都搞架构评审，结果到后来大家就是走个过场，根本没人认真看。
我的经验是：
- 正式评审：每个里程碑一次，大约每4-6周一次
- 非正式评审：遇到重大变更时随时发起
- 专项评审：针对安全关键模块、新引入的技术栈等
避坑指南：我曾经犯过一个错误——在架构还没稳定的时候就组织了正式评审。结果评审完第二天，需求变了，架构也跟着改。那次评审的结论全部作废，白白浪费了大家两天时间。所以记住：评审的时机比频率更重要。
1.4 我的个人建议
做了这么多年架构评审，我总结了几条经验，分享给你：
- 评审前一定要准备：提前3-5天把材料发给评审人员，让大家有时间看。临时抱佛脚的评审，效果打五折。
- 控制评审时长：一次评审不要超过2小时。超过这个时间，人的注意力就开始下降了。如果内容多，可以分多次评审。
- 记录要详细：评审结论、问题清单、责任人、截止日期，一个都不能少。没有记录的评审，等于没评。
- 跟踪闭环：评审发现的问题，一定要跟踪到解决为止。我见过太多评审问题「石沉大海」的情况了。
嗯，关于架构评审的概述，就先聊这么多。下一章我们会深入讲评审的具体方法和流程。记住一句话：好的架构是评审出来的，不是画出来的。