如何做 Code Review


Why we need code review

产品开发周期内,代码编写所占的时间比例其实是很小的,除了要做编码前的工程设计,还需要花大量的时间在代码调试,修复 Bug 和填之前的坑上。做 Code Review ,是为了减少代码调试的时间,更快的定位和修复 Bug 和少挖一些坑。在代码编写的阶段通过 Code Review 把控质量,从总的项目周期来看是划算的,甚至是事半功倍的。

好的代码没有统一的标准,但是不外乎几个标准,结构合理、低耦合、易读、可扩展。而代码评审,提供了一个机会,让大家对代码的实现,发表自己的意见,能避免一个人构思的局限性。

怎么做 Code Review

每次 Review 的粒度,不要很大。如果可以,不要等一个功能的全部开放完成, 再提交。例如一些基本的代码,可以先合到 master 也不影响现有的代码,就可以先提交。又例如测试部分的代码,也可以另外提交。

也可以由一人负责写代码,一人负责跟踪和讨论,然后交叉进行,有点类似结对编程。

Reviewer 应该怎么做:

  1. 对码不对人
  2. 语音平和
  3. 适当感谢

Developer 应该怎么做:

  • 保持适当的自尊心
  • 记住:每个人都会犯错
  • 学会感激

总的来说,代码编写过程中尽可能多的和别人讨论沟通,让评审者充分了解你的工作。

Code Review 究竟要 Review 什么

Review 最基本要求,是检查代码可能隐藏的 bug。其次,是对代码质量的把关,避免改动引入新的 Bug 。另外,对改动的代码,是否做到了易读、易维护、结构清晰、实现合理。

从 Code Review 中得到什么

Code review 的目的不仅仅是为了把控代码质量,还有提高工作效率。Code Review 应该成为企业文化的一部分,公司员工对 Code Review 的重视程度,体现着这家公司对工程、对代码的态度。

刚入职的时候,每次发起 Review 都有些害怕,因为每次都会被找出一堆问题,每次都要经过好几回的修改,才能通过。后来就渐渐习惯了,不再害怕,别人指出问题之后,也不会觉得沮丧,反而觉得自己学到很多。之后自己去 Review 别人的代码,也认真去做到细致、负责。

最近的工作,另外项目组的同事需要改动我在的组所负责的项目,由他们组开发,我来评审,但是由于两个组沟通不够充分,而我也不够熟悉需求,当我在评审的时候,往往只是看看有没有简单的错误而已,没有做更深层次的 Review ,因此导致后续测试的时候,发现了一堆 Bug 和漏掉需求没有实现的情况。为了去修复这些问题,后来还花了不少时间,实在得不偿失。

References