4、评审类型：正式评审、技术评审、走查、结对评审
说到评审类型，很多团队其实搞混了。我见过不少项目，把「走查」当「正式评审」开，结果大家坐在一起读代码，效率低得吓人。今天咱们把这四种类型掰开揉碎了讲清楚。
4.1 正式评审（Formal Review）
正式评审，说白了就是最重、最严格的那一套。它通常用在架构设计的关键节点上，比如系统需求分析、软件架构基线评审。
我个人习惯把正式评审比作「法庭审判」——有法官、有陪审团、有证据、有判决。流程上，它要求：
- 提前准备：评审材料至少提前3天发给评审员
- 角色明确：主持人、记录员、作者、评审员各司其职
- 有检查单：按条目逐项过，不能跳着看
- 有结论：通过、有条件通过、不通过，三种结果必须明确
关键点：正式评审的产出不是「改完就完」，而是要有正式的评审报告，记录所有发现项、责任人、整改期限。
我在项目中遇到过一件事：某次正式评审，主持人没提前发材料，大家现场翻文档。结果3小时的会，2小时在沉默，最后草草收场。嗯，那次评审基本等于白开。
4.2 技术评审（Technical Review）
技术评审比正式评审轻一些，但比走查重。它更关注「技术方案对不对」，而不是「流程走没走完」。
你想想看，技术评审的场景是什么？通常是架构师出了个方案，想听听同行意见。比如「这个通信中间件选型合不合理？」「这个分区方案有没有隐患？」
技术评审的特点：
- 参与者是技术专家：不一定要项目经理、QA都来
- 关注技术细节：比如接口设计、时序约束、资源冲突
- 结果灵活：可以当场改，也可以会后改，不强制走流程
我的建议：技术评审最好控制在1.5小时内。超过这个时间，大家的注意力就开始散了。如果内容多，拆成两次开。
我记得有一次做AUTOSAR架构的技术评审，大家就「RTE层要不要做静态内存分配」吵了40分钟。最后发现两边说的其实是同一个意思，只是术语理解不同。所以啊，技术评审里「统一术语」比「统一结论」更重要。
4.3 走查（Walkthrough）
走查，很多人叫它「读代码会」。其实走查不光是读代码，也可以读设计文档、读需求规格。
走查的核心是「作者主导，大家跟着过一遍」。它不像正式评审那样有严格的角色分工，也不像技术评审那样聚焦技术决策。走查更像「大家一起找茬」——作者念，大家听，发现问题就记下来。
走查的适用场景：
- 代码审查：新模块的代码，作者一行行讲
- 需求澄清：需求写得太模糊，走查一遍看看有没有歧义
- 新人培训：让新人走查老代码，快速熟悉业务
避坑指南：我曾经见过一个团队，走查开了4小时，最后发现大家根本没看材料。走查最怕「现场读文档」——效率极低。正确的做法是：作者提前发材料，大家提前看，会上只讨论有疑问的地方。
走查有个好处：它不挑人。实习生、新同事都可以参与。我建议团队每周固定一个「走查时间」，哪怕只有30分钟，也能发现不少隐藏问题。
4.4 结对评审（Pair Review）
结对评审，说白了就是两个人一起干活。它和结对编程有点像，但更侧重「评审」而不是「开发」。
结对评审的典型场景：
- 关键模块：比如安全相关的代码，两个人一起过一遍
- 新人带教：老手带新手，边评审边讲解
- 紧急修复：线上问题需要快速改，两个人一起审效率更高
结对评审的好处是「即时反馈」。你写一行，我看一行，有问题当场就改。不像正式评审，发现问题还要等会后改。
效率对比：
| 评审类型 | 准备时间 | 会议时长 | 发现缺陷率 | 适合场景 |
|---|---|---|---|---|
| 正式评审 | 高（3天+） | 2-4小时 | 高 | 架构基线、安全关键设计 |
| 技术评审 | 中（1-2天） | 1-2小时 | 中高 | 技术方案、接口设计 |
| 走查 | 低（提前看即可） | 0.5-1小时 | 中 | 代码审查、需求澄清 |
| 结对评审 | 无（即时） | 灵活 | 中高 | 关键模块、紧急修复 |
4.5 怎么选？
很多团队问我：「到底该用哪种评审？」我的回答是：看场景，别死板。
- 安全关键模块（比如ASIL D的代码）：必须正式评审，别省
- 架构设计初稿：先走查或技术评审，等稳定了再正式评审
- 日常代码：走查或结对评审就够了，别动不动开大会
- 紧急问题：结对评审最快，两个人搞定
我的经验：一个健康的团队，四种评审类型都会用到。但比例很重要。我建议：正式评审占10%，技术评审占30%，走查占40%，结对评审占20%。这样既保证了关键节点的质量，又不会让评审成为负担。
最后说一句：评审不是走过场。你想想看，如果评审只是为了「完成流程」，那还不如不评。真正有效的评审，是能发现问题的、能推动改进的、能让团队成长的。
嗯，今天就聊到这儿。下一章咱们聊聊「评审角色与职责」，这个也很关键——角色分不清，评审就容易乱。