4、架构设计评审：嵌入式系统架构设计原则，如何组织高效的架构评审会议。

架构评审，这个词听起来挺正式的。但说白了，它就是一场「找茬会」。

我见过太多团队，评审会开成了「汇报会」。架构师在上面讲PPT，下面的人刷手机。最后问一句「大家有问题吗？」——全场沉默。然后项目就带着一堆隐患往下走了。

为什么会这样？因为大家没把评审当成自己的事。今天我就聊聊，怎么把这场会开得有价值。

4.1 嵌入式架构设计的三个核心原则

在讲评审方法之前，得先明确一个前提：我们评审什么？

我个人习惯，评审时重点盯住三个原则。如果这三个点没问题，架构基本就稳了。

原则一：模块化与解耦

嵌入式系统最怕什么？牵一发而动全身。

我遇到过最惨的一次，就是修改了一个驱动层的定时器参数，结果应用层的UI刷新全乱了。原因就是模块之间耦合太紧，一个全局变量被到处引用。

好的架构，模块之间应该是「高内聚、低耦合」的。每个模块只干一件事，接口清晰，依赖明确。

原则二：资源可预测性

嵌入式系统资源有限。RAM、ROM、CPU时间，都是硬约束。

你想想看，一个架构设计得再漂亮，如果跑起来内存溢出、CPU满载，那就是废纸一张。

我记得有一次评审一个通信协议栈的架构。设计者用了大量的动态内存分配，看起来很灵活。但我问了一句：「最坏情况下，内存占用是多少？」他答不上来。后来一算，峰值内存比可用RAM还多出30%。这个架构直接被否了。

原则三：可测试性与可维护性

这个原则，很多团队会忽略。他们觉得「先跑起来再说」。

但你想过没有？一个不可测试的架构，出了问题你根本不知道是哪里崩的。一个不可维护的架构，三个月后连原作者都看不懂。

我个人的经验是：在架构设计阶段，就要把测试接口留好。比如，为每个模块设计一个「自测模式」，可以在不依赖硬件的情况下跑单元测试。

4.2 如何组织高效的架构评审会议

原则讲完了，接下来是实操。怎么把评审会开好？

我参加过很多低效的评审会。有的开了4个小时，最后什么都没定下来。有的变成了「批斗会」，大家互相指责。还有的干脆就是走过场。

嗯，这里要注意。高效的评审会，需要做好三件事：会前准备、会中控制、会后跟踪。

会前准备：资料提前发，别在会上读PPT

这是最基础，但也是最多人做不到的一点。

我要求团队：评审资料至少提前2天发出去。评审会上，默认大家已经看过了。会上只讨论问题，不读文档。

会中控制：时间要短，节奏要快

我个人建议，一次评审会不要超过90分钟。超过这个时间，人的注意力就开始下降了。

会议流程可以这样安排：

时间段	内容	负责人
0-15分钟	架构师快速过一遍核心设计（只讲重点和变更点）	架构师
15-60分钟	逐模块评审，聚焦问题讨论	全体
60-75分钟	风险识别与应对方案	全体
75-90分钟	总结结论，明确待办事项	主持人

会后跟踪：结论要落地，问题要闭环

评审会开完了，不等于事情结束了。

我见过最糟糕的情况：评审会上提了20个问题，会后一个都没改。下次评审还是同样的问题。

所以，每次评审会必须输出一份《评审结论报告》，包含：

• 通过/有条件通过/不通过：明确结论，不要模棱两可。
• 待办事项清单：每个问题指定责任人、截止时间。
• 遗留风险：暂时无法解决的问题，记录在案，后续跟踪。

4.3 评审中常见的「坑」与应对

做了这么多年架构评审，我踩过不少坑。分享几个典型的：

坑一：评审变成了「说服会」

架构师花大量时间证明自己的方案是对的，而不是听取意见。

应对： 主持人要明确角色。架构师是「被评审者」，不是「辩护律师」。评审的目的是发现风险，不是证明谁对谁错。

坑二：只评审代码，不评审架构

有些人喜欢在评审会上看具体的代码实现，而不是看架构设计。

应对： 明确评审边界。架构评审只看模块划分、接口定义、数据流、资源分配。具体的代码实现，留给代码评审去处理。

坑三：人太多，意见太杂

我曾经参加过一个评审会，来了20多个人。每个人都有自己的想法，最后吵成一锅粥。

应对： 控制参会人数。核心评审人员不超过5人，包括：架构师、技术负责人、测试负责人、硬件负责人（如果涉及硬件）。其他人可以旁听，但只有发言权，没有表决权。

好了，这一章就聊到这里。下一章我们讲讲「代码评审」——那个让程序员又爱又恨的环节。