Why we need code review
产品开发周期内，代码编写所占的时间比例其实是很小的，除了要做编码前的工程设计，还需要花大量的时间在代码调试，修复 Bug 和填之前的坑上。做 Code Review ，是为了减少代码调试的时间，更快的定位和修复 Bug 和少挖一些坑。在代码编写的阶段通过 Code Review 把控质量，从总的项目周期来看是划算的，甚至是事半功倍的。
好的代码没有统一的标准，但是不外乎几个标准，结构合理、低耦合、易读、可扩展。而代码评审，提供了一个机会，让大家对代码的实现，发表自己的意见，能避免一个人构思的局限性。
怎么做 Code Review
每次 Review 的粒度，不要很大。如果可以，不要等一个功能的全部开放完成， 再提交。例如一些基本的代码，可以先合到 master 也不影响现有的代码，就可以先提交。又例如测试部分的代码，也可以另外提交。
也可以由一人负责写代码，一人负责跟踪和讨论，然后交叉进行，有点类似结对编程。
Reviewer 应该怎么做：
- 对码不对人
- 语音平和
- 适当感谢
Developer 应该怎么做：
- 保持适当的自尊心
- 记住：每个人都会犯错
- 学会感激
总的来说，代码编写过程中尽可能多的和别人讨论沟通，让评审者充分了解你的工作。
Code Review 究竟要 Review 什么
Review 最基本要求，是检查代码可能隐藏的 bug。其次，是对代码质量的把关，避免改动引入新的 Bug 。另外，对改动的代码，是否做到了易读、易维护、结构清晰、实现合理。
从 Code Review 中得到什么
Code review 的目的不仅仅是为了把控代码质量，还有提高工作效率。Code Review 应该成为企业文化的一部分，公司员工对 Code Review 的重视程度，体现着这家公司对工程、对代码的态度。
刚入职的时候，每次发起 Review 都有些害怕，因为每次都会被找出一堆问题，每次都要经过好几回的修改，才能通过。后来就渐渐习惯了，不再害怕，别人指出问题之后，也不会觉得沮丧，反而觉得自己学到很多。之后自己去 Review 别人的代码，也认真去做到细致、负责。
最近的工作，另外项目组的同事需要改动我在的组所负责的项目，由他们组开发，我来评审，但是由于两个组沟通不够充分，而我也不够熟悉需求，当我在评审的时候，往往只是看看有没有简单的错误而已，没有做更深层次的 Review ，因此导致后续测试的时候，发现了一堆 Bug 和漏掉需求没有实现的情况。为了去修复这些问题，后来还花了不少时间，实在得不偿失。