- 如何保证代码都被Review？人一是有惰性，二是习惯问题，可能会导致有些代码没有Review而进入了代码库。如果你用Gitlab系统，可以把主分支设置为protected，不准任何人push。开发只能在分支上进行，开发完后，在网页上发一个merge request。请其他人Review后，merge到主分支上。
- Review的规模多大？代码如果太多，涉及太多特性，Review的时间可能会很长，Review的内容也会很多，这会不利于Review的效率和效果。Google给Review代码的长度定了一些名称，比较适合的是在100行以内。每次Review的特性要尽量少，如果你Review的内容混合了好几个特性，就很难分清楚。
- Review的职责是可读性、可扩展性、设计模式、程序逻辑等方面。首先你要能完全看懂这部分代码，了解他们的业务实现。并可以思考有没有改进、重构的空间，是否有更好的设计，是否有更好的性能。
- 不应该是找Bug这是单元测试、协议测试、集成测试的内容，当然，可能也会发现，但发现Bug不是目标。
- 不应该负责代码风格。代码风格在提交的时候就应该是好的。
- Review的方式是，叫人过来，坐你旁边，开始讲解你的设计和编码。先讲你的设计思路，然后讲代码实现。
- 尽量让不同人的Review，而不是让“领导”Review
- Review要仔细，要详细了解设计、编码，不能蜻蜓点水。一般来说，100行代码的变动Review要一个小时左右，可以作为一个参考值。
- 可以用版本的diff查看哪些被改动了，不过重点Review最好还是在IDE上，可以联系上下文进行阅读。diff工具往往就显示了改动，反而不好阅读。