我理解的Code Review

一直以来团队都有Code Review的诉求,之前大部分时候都是看到哪里有问题直接改掉,或者群里抛出来,直到最近才开始认认真真的执行了两次,执行效果虽在进步,但也不是特别理想。总结下来应该是共识不统一造成的,都觉得应该进行Code Review,但是为什么做,怎么做,并没有一开始的宣导和定义。

为什么要做Code Review?
这个相信大家心里都有普,都能说上几条好处,比如:
1.可以提高代码质量及可维护性。这样就可以减少查找错误的时间,提高解决bug的效率,提高开发效率的同时降低后期的维护成本。
2.统一团队规范,让代码是能够迅速被项目组其他成员看懂的,这样有利于项目其他成员更全面的了解业务,对于成员之间交流也有很好的促进作用,可以让新人尽快的融入和适应。
3.可以有效的团队技术水平以及业务能力,促进大家共同进步。
总之进行code review的好处多多,初衷一定是为了找出问题,提高代码质量,而更大的意义在于提高大家讨论和提出问题,思考问题的能力,提高团队学习氛围。

我理解的Code Review应该分成两种:代码审查(commit review)和 代码走查(team review)
1.代码审查—commit review(参与人:开发者、模块Owner/Senior Engineer)
代码审查,相对比较正式,有的公司要求更改和提交代码必须要有人审核过才可以。有的甚至还要发邮件列出改动点,我们之前做的fireEye review系统也属于这一种;通常由一些比较senior或者模块的owner负责审查工作,侧重点一般为:

  • 基本功能是否实现,逻辑是否正确
  • 代码实现清晰易读吗
  • 有没有没有考虑到的点,特别是对其他部分代码会否造成影响
  • 是不是最好的实现,有没有重构的空间

2.代码走查—team review(参与人:团队成员一起)
代码走查,没那么正式,更倾向于团队成员在一起就一个文件代码进行一起交流和分享。
时间不宜过长,一次review讲解业务和逻辑的时间太长,Code Review效果就会想下降,最好控制在30分钟左右。
经过走查的代码应该是参加成员大部分能认同的,并且参加者每个人都能读懂的逻辑清晰的代码。

我们目前还处于婴儿学步的阶段,才开始进行一些team review,标准还未统一。为了让Code Review达到更好的效果,接下来要做的还很多:

  • 增加commit review:有的项目参与的人比较多,每个人的习惯和写法都不一致,有的小伙伴新参与并不知道其他人已经封装了公共组件,又重复劳动,对于新参与项目或者修改其他人代码的项目,增加ower review(实际开发过程中,由于需求时间和审核人经历限制,只能先对一些比较重要的项目,或者项目不太了解的同学做review)
  • commit注释规范:制定团队注释规范,注释要清晰明了,不能太短或者无意义提交
  • 统一团队Code Review规范
  • Code Review要记录问题,达成共识的问题要及时修改