4. 评审类型与时机选择：正式评审、技术走查、结对评审、同行评审，何时用哪种？
评审这件事，说起来简单——不就是找人看代码吗？但我在项目里见过太多「评审变批斗会」或者「评审走过场」的情况。说白了，选错评审类型，比不评审还糟糕。
嵌入式开发有个特点：硬件耦合深、实时性要求高、出了问题很难远程打补丁。所以评审类型的选择，直接决定了你是真发现问题，还是浪费时间。
我个人习惯把评审分成四类：正式评审、技术走查、结对评审、同行评审。它们各有各的脾气，用对了地方就是利器，用错了就是内耗。
4.1 四种评审类型速览
先给个总览表格，方便你快速对照。后面我再逐个拆解。
| 评审类型 | 核心特点 | 典型时长 | 参与人数 | 正式程度 |
|---|---|---|---|---|
| 正式评审 | 有流程、有角色、有记录、有结论 | 1-2 小时 | 5-8 人 | ★★★★★ |
| 技术走查 | 作者主导，逐行讲解，听众提问 | 30-60 分钟 | 3-5 人 | ★★★☆☆ |
| 结对评审 | 两人实时协作，边写边审 | 持续进行 | 2 人 | ★★☆☆☆ |
| 同行评审 | 非正式，异步或同步，侧重经验分享 | 15-30 分钟 | 2-4 人 | ★★☆☆☆ |
核心原则：评审的正式程度，应该与文档/代码的关键程度成正比。一个启动加载器的初始化代码，不值得开 2 小时正式评审；但系统架构变更，绝对不能只靠结对评审带过。
4.2 正式评审：什么时候必须上「重武器」？
正式评审，说白了就是「开大会」。有主持人、有记录员、有评审组长，会前要发材料，会后要出报告。听起来很重，但有些场景非它不可。
我建议在以下场景使用正式评审：
- 架构设计文档：系统模块划分、接口定义、任务调度策略。这些一旦定下来，后面改动的成本极高。
- 关键安全功能：比如汽车电子的 ASIL-D 级别代码、医疗设备的生命支持逻辑。这类代码出问题不是 bug，是事故。
- 跨团队接口协议：比如 CAN 总线报文定义、SPI 通信协议、内存布局约定。多个团队依赖同一个接口，必须白纸黑字确认。
- 重大重构方案：涉及架构级变更时，需要多方达成共识。
我曾经踩过的坑：有一次我们团队对 Bootloader 的升级流程做了改动，觉得「代码量不大，走个结对评审就行了」。结果上线后，升级过程中断电导致设备变砖。后来复盘发现，问题出在状态机跳转逻辑上——结对评审的两个人都是开发思维，没人从测试和运维角度去审视。从那以后，凡是涉及状态机、异常恢复、安全降级的设计，我坚持走正式评审，至少拉上测试和运维的人一起。
正式评审的典型流程：
- 作者提前 2-3 天发送评审材料
- 评审人独立预审，记录问题
- 召开评审会议，逐条讨论
- 记录决议：通过 / 有条件通过 / 重新评审
- 作者整改，评审组长确认关闭
4.3 技术走查：最被低估的高效评审方式
技术走查，很多人觉得它「不够正式」，但我个人认为它是嵌入式开发中性价比最高的评审方式。
怎么操作？作者坐在屏幕前，打开代码或文档，逐行逐段地讲给听众听。听众随时打断提问。不需要提前准备材料，不需要写评审报告。
技术走查最适合的场景：
- 驱动层代码：寄存器操作、中断处理、DMA 配置。这些代码逻辑密集，走查时能发现很多「想当然」的错误。
- 算法实现：比如 PID 控制、卡尔曼滤波、FFT 处理。作者边讲边推导，听众能及时发现边界条件遗漏。
- 中等复杂度的模块：一个模块几百行代码，逻辑清晰但细节多。走查比正式评审灵活，比结对评审有更多视角。
- 新人代码审查：新同事写的代码，走查是最好的带教方式。我见过太多新人被正式评审吓到不敢说话，但走查时能主动问出很多好问题。
一个小技巧：技术走查时，我要求作者不要提前给听众发代码。为什么？因为一旦提前发了，听众会自己看，走查时就变成了「我已经看过了，没什么好问的」。现场逐行讲解，反而能逼着听众跟着作者的思路走，更容易发现逻辑断层。
4.4 结对评审：日常开发的最佳拍档
结对评审，其实就是两个人坐在一起写代码。一个人写，另一个人实时看。这不是「一个人写、一个人玩手机」，而是真正的实时协作。
结对评审最适合的场景：
- 复杂逻辑的首次实现：比如一个状态机、一个协议解析器。两个人一起推演，能避免很多低级错误。
- 调试疑难 bug：一个人卡住了，另一个人换个视角，往往能快速定位问题。
- 新人上手：让有经验的工程师带着新人结对，比任何文档培训都有效。
- 紧急修复：线上问题需要快速出补丁，结对评审既能保证速度，又能保证质量。
注意：结对评审不是「一个人写、一个人看」，而是两个人轮流「驾驶」。我习惯每 30 分钟换一次角色。写的人专注实现，看的人专注「这里是不是漏了边界检查？」「这个变量命名会不会误导人？」。两个人保持对话，而不是沉默。
4.5 同行评审：轻量级的「第二双眼睛」
同行评审，是最轻量级的方式。不需要开会，不需要预约会议室。你写完一段代码，发给另一个工程师，他抽空看看，给你反馈。或者你们在茶水间聊两句：「诶，我这个中断处理函数你帮我瞄一眼？」
同行评审最适合的场景：
- 非关键模块的日常代码：比如日志模块、工具函数、配置解析。这些代码出问题影响不大，不需要大动干戈。
- 文档初稿：设计文档的第一版，先让同行看看结构是否合理，再决定要不要走正式评审。
- 经验分享：你发现了一个好用的设计模式，或者踩了一个坑，找同行聊聊，互相学习。
- 跨领域检查：硬件工程师看软件工程师的寄存器配置，软件工程师看硬件工程师的时序图。这种交叉检查，正式评审太隆重，同行评审刚刚好。
我曾经犯过的错：有一段时间，我觉得同行评审「太随意」，所有代码都走正式评审。结果团队评审效率直线下降，大家开始抵触评审。后来我才明白，不是所有代码都值得 2 小时会议。把同行评审当作日常习惯，把正式评审留给真正重要的节点，这才是健康的评审文化。
4.6 如何选择？一张决策流程图
说了这么多，到底怎么选？我画了一张决策流程图，你可以贴在工位上。
4.7 我的经验总结
做了这么多年嵌入式，我总结了几条关于评审时机的「潜规则」：
- 不要等代码写完再评审。我习惯在「设计阶段」就做一次技术走查，确认思路没问题再动手。否则写完了发现方向错了，返工成本太高。
- 评审频率和项目节奏挂钩。项目初期（架构阶段）多用正式评审，中期（编码阶段）多用技术走查和结对评审，后期（集成测试阶段）回归正式评审做验收。
- 评审不是考核，是协作。我见过一些团队把评审当成「找茬」，搞得人人自危。其实评审的目的是帮作者发现问题，不是证明作者不行。你想想看，如果评审氛围不好，谁还敢把代码拿出来审？
- 工具只是辅助，人才是核心。不管用 GitLab MR 评审、Gerrit 还是 Jira，工具解决不了「评审文化」的问题。我见过用最简陋的邮件列表做评审的团队，效果比用高大上工具的团队好得多——因为他们真的在认真看代码。
一个小建议：如果你刚开始建立评审流程，别一上来就搞正式评审。先让团队养成「同行评审」的习惯，每天花 15 分钟互相看看代码。等大家习惯了被审视、也习惯了审视别人，再逐步引入技术走查和正式评审。评审文化是养出来的，不是管出来的。
嗯，关于评审类型和时机选择，就聊到这里。记住一句话：没有最好的评审方式，只有最合适的评审方式。关键是根据文档/代码的重要程度、复杂程度和紧急程度，灵活切换。