第4章评审类型

4. 评审类型：正式评审、技术评审、走查、同行评审、非正式评审

说到评审类型，很多人一开始会觉得头大。什么正式非正式，走查同行评审，感觉像绕口令。其实没那么复杂，我习惯把它们分成两类：一类是「穿西装的」，一类是「穿T恤的」。说白了，就是看你要多严肃地对待这件事。

我在项目中见过不少团队，一上来就搞正式评审，结果大家坐在一起大眼瞪小眼。为什么？因为评审类型没选对。你想想看，一个刚写完的草稿，你非要拉上总监、架构师、产品经理一起过，那不是浪费大家时间吗？

好，咱们一个一个来看。

正式评审，就是最正规、最隆重的那种。它有一套完整的流程：会前准备、角色分工、会议记录、问题跟踪、结论确认。每一步都不能少。

核心特征：

我个人习惯，正式评审用在关键节点上。比如需求基线评审、架构设计评审、重大变更评审。这些地方出了问题，后面返工成本太高，必须用正式评审来把关。

我的经验：正式评审最怕什么？最怕大家没提前看材料。我曾经遇到过一次评审，20页的文档，现场让作者从头念了一遍。那叫一个煎熬。后来我定了个规矩：会前24小时发材料，没看完的，评审延期。效果立竿见影。

技术评审，重点在「技术」两个字。它不像正式评审那么讲究流程，但更关注技术细节。比如接口设计、数据库表结构、算法实现、安全方案等等。

技术评审的参与者，通常都是技术人员。产品经理、业务方一般不参加。为什么？因为聊的都是技术实现，他们听了也白听。

我记得有一次做支付系统的技术评审，大家争论一个接口是同步还是异步，吵了半小时。最后发现，其实业务场景决定了必须异步。你看，技术评审如果不结合业务场景，就容易钻牛角尖。

注意：技术评审容易变成「技术辩论赛」。我建议定个规则：每个议题讨论不超过15分钟，超时了先记下来，会后单独聊。不然一个评审会能开一整天。

走查，英文叫 Walkthrough。这个词很形象，就是「走一遍」。作者带着大家，把文档或代码从头到尾过一遍。走查的特点是：作者主导，其他人边听边提问题。

走查适合什么场景？我觉得最适合需求文档和测试用例。为什么？因为这些文档需要「通读」才能发现逻辑漏洞。你光看片段，很难发现前后矛盾的地方。

我曾经带过一个测试团队，每次写测试用例都做走查。怎么做的？很简单：测试工程师打开用例，一条一条念，大家听。听到不对劲的地方就喊停。这个方法虽然土，但特别有效。有一次走查中发现了三个业务逻辑漏洞，要是上线了，那就是P0事故。

走查的要点：

同行评审，Peer Review，这个词在软件开发里太常见了。说白了，就是让和你水平差不多的人来看你的东西。代码审查（Code Review）就是最典型的同行评审。

同行评审的好处是什么？我总结了两点：

但同行评审也有坑。我见过一个团队，Code Review变成了「走过场」。每个人点个「Approved」就完事了，根本没人认真看。为什么会这样？因为大家太忙了，觉得Review是额外负担。

我的建议：把同行评审纳入开发流程，而不是附加任务。比如我们团队规定：没有经过Review的代码，不能合并到主分支。这个规矩一旦立起来，大家自然就重视了。

非正式评审，就是最轻松的那种。没有流程，没有角色，没有会议纪要。可能就是两个人坐在工位上，对着屏幕聊一聊。或者拉个群，发个文档，大家随手评论几句。

非正式评审适合什么时候用？我习惯在早期阶段用。比如需求刚有个雏形，设计还在画草图，这时候搞正式评审太早了。不如先找一两个信得过的同事，随便聊聊，把大方向定下来。

你想想看，一个需求还在「想法阶段」，你非要拉个正式评审会，那不是搞笑吗？非正式评审的好处就是灵活、快速、低成本。

但是要注意：非正式评审的结论，一定要记录下来。我吃过这个亏。有一次和产品经理口头聊了一个需求变更，双方都「嗯嗯」表示同意。结果两周后开发完了，产品说「不对啊，我说的不是这个意思」。从那以后，哪怕是非正式评审，我也会在聊天记录里发一条总结：「刚才我们聊的，我理解是XXX，对吗？」

好，五种评审类型都讲完了。你可能会问：那我到底该用哪一种？

我个人的选择逻辑是这样的：

最后说一句：评审类型不是死的。同一个项目，不同阶段可以用不同的评审方式。灵活一点，别把自己框死了。