1\传播知识。
相信很多人第一次提交 Code Review 都有类似的经历：短短几百行代码，却被提了密密麻麻几十条 comments，更新了十多次代码，才最终被 accept 。其实当代码被 accept，提交代码的工程师通过这次 review 就学习到了代码规范和很多好的实践。同时，通过 review 更资深工程师的代码，年轻的工程师也更直观地学习架构和编码；另外，工程师之间也可以通过 review 代码来共享项目知识，看代码实现在绝大多数时候是了解项目的最好方式。
2、增进代码质量。
这点也很容易理解，有经验的工程师可以在架构设计、代码细节等各个方面帮助到初学者。不同工程师也会有知识盲点，互相 review 进步也很快。另外，被 review 的代码质量更高还有一个很多人注意不到的心理因素：在状态不佳的时候，工程师难免会匆忙写些“潦草”的代码，但是当你知道自己的代码会被review 的工程师提交 comment 打回来，自然会更仔细些 : -)
3、找出潜在的 bug。
这是大部分团队进行 Code Review 的目的。就像上面提到的，Code Review 在这方面效果不错。其实我认为大部分代码 bug 应该由单元测试，功能测试，性能测试和回归测试来保障。不过由于静态分析不理解业务，另外有些 bug 在测试中并不容易复现，这两种情况下，经验丰富的工程师来 review 代码就尤其重要了。
接下来想谈的是做 Code Review 的根本原因是什么。
毕竟 Code Review 是在编码过程中加了一道流程，又需要很多交流沟通，review 双方甚至可能由于编程理念不一样而产生争执，各种原因导致做好 Code Review 并不容易。现实情况确实如此，比如 v2ex 上有个帖子：发起个讨论，你们公司有 code review 吗？ ，一百多位工程师回答了这个问题，从他们的答案中可以看出，做好 Code Review 的公司寥寥无几。即使在一线互联网公司，也有不少团队反对 Code Review ，陈皓就写过一篇文章：《从Code Review 谈如何做技术》 ，提到了在阿里实施 Code Review 遇到的阻力，反对的原因是工期紧、需求变更快。如果不想清楚为什么要做 Code Review ，遇到障碍会非常容易妥协，慢慢 Code Review 就会走样，最终流于形式。反之，在我们遇到障碍，review 代码不顺利时就会以积极的心态来解决问题。
在我看来，我们在完成编码工作的同时，也需要时时分享架构设计，交流各自的代码，Code Review 正是时时分享架构设计，交流代码最好的方式。这是我们需要做 Code Review 的根本原因。交流代码的频率非常重要，在你构思好设计，有了骨架代码，写完一个功能后都应该及时提交 review，以便其他工程师能够及时了解你的思路，和你沟通实现细节。而那些认为代码只要能运行就好，或者认为没人应该对自己代码指手画脚的人显然和你我不同，他们不会是这篇文章的读者 :
那么我们怎样做好 Code Review 呢？两个方面：一是减负，Code Review 只做它应该做的事情。二是提高 Code Review 的效率。
Code Review 应该讨论的是功能实现、架构设计、代码质量，不应该做以下两件事情。
1、检查代码风格和编程规范。
除了新人，其他工程师提交的代码不应该通过 review 来确保代码风格。这里所说的代码风格包括但不限于：命名规范、代码缩进、注释和文档等等。你可以利用 IDE 或者其他工具来保证编程规范和代码风格的统一。如果你在制定团队的代码规范，可以 follow Google Java Style 或者 Facebook Coding Standards 。在这里我推荐好好看看 Facebook 的规范，因为 Google 的代码规范告诉你应该怎么做，而 Facebook 的规范解释了为什么要这样做，以及在什么情况下需要权衡。
来源：oschina
链接：https://my.oschina.net/mdxlcj/blog/4748927