如何进行真正有效果的review (评审)? 能不开的会是坚决不能开的

入职不久的一位研发同学希望能组织一个会议讨论评审他做的设计，我告诉他，你先看一下我写的一篇公司内部博客。今天把我写的这篇内部博客公开出来，希望能给业内的研发同学特别是研发负责人一点启发。

我们在实际工作中，经常要做各种review (评审), 包括设计、代码、文档等等。大家习惯性的做法，是召集相关的人开会，内容的负责人会走读一次，介绍一下，为什么这么做，这么写，然后汇集大家的意见做些调整。通过多年的实践，我认为这套方法是走过场的，是形式主义的review，难以达到review的目的。表现在几个方面：

1. review的人没有做充足准备，思路只能跟着主讲人的思路跑，发现的问题往往是违反规范，或其他显而易见的问题；

2. review的人提的问题是现场提的，不是经过思考提出来的，因此有可能是不完整的，甚至不合逻辑或错误的；

3. 参与开会的人，很多是心不在焉的，整个会议是一句话都不说的，完全没有产出。

那么怎么做有效果的review呢？我们需要做到以下几点：

1. 内容负责人提前准备好内容：对照<Amazon 的秘密管理武器 - 「6页备忘录」> 检查一下内容是否满足要求。对于特别具体的文档，比如背景、解决的问题或需求大家都十分清晰的，准备的内容可以直奔主题（但建议用参考文档的方式放在内容最后，以免有不熟悉了解的人）

2. 在Confluence的文档里直接@，或飞书通知相关的人进行review，并给出需要收到review回复的时间。