如何做代码评审?

谈及TDD的好处时,其中之一就是随时随地的Code Review,所以,貌似TDD是不需要Code Review的。但实际上,TDD和Code Review是两个正交的维度,做TDD并不妨碍Code Review。

这里就来聊聊我所在的项目是如何做Code Review的。我们有两种Code Review:Daily Code Review和Weekly Code Review。之所以有两种Code Review,因为每种Code Review的目的是不同的。

Daily Code Review

顾名思义,这是一种每天都做的Code Review。它的目的是让项目组全体成员了解每天的项目进展。

每天早上,运用git(这里可以替换成你所用的版本控制软件)的diff功能,找出前一天修改。全项目组的人在一起,逐行浏览这些修改。每当过到一处修改,这段代码的修改者就会针对修改,介绍一下这是哪个功能,为什么要做这些修改。项目组的其他人如果对这段代码有异议,都可以提出自己的问题。

这种Code Review使用的diff功能,了解的基本上只是一个片段,所以,关注点基本上是Clean Code。最经常出现的问题是,这段代码为什么写成这样。对于项目组的新人而言,这种Code Review是一个非常好的学习Clean Code以及了解项目隐含编码约定的机会。

Daily Code Review结束之后,每个人会针对其他人提出的修改意见对代码进行调整。在开始新一天的工作之前,最大程度地保证了代码库的整洁。

Weekly Code Review

诚如之前所述,Daily Code Review只能了解一个片段,人们缺乏对一个功能或一个故事的整体认识。Weekly Code Review弥补了这种缺陷。

Weekly Code Review更类似于许多企业的传统Code Review方式。由专人(一个人或一对pair)选取一个近期开发比较大的功能(或故事),组织全项目组的人进行Review。

在这个过程中,组织者会带领所有人浏览针对这个功能的相关代码。我们的主要关注点是让项目组的所有人对这个功能有所了解。这时项目组成员,也会从业务逻辑,以及局部设计的角度对代码进行分析,提出一些改进建议。如果过程中出现了一些难于理解的部分,组织者要负责为大家答疑解惑。

同样,在Weekly Code Review中发现的问题,也会被修正到代码之中。

无论是Daily Code Review还是Weekly Code Review,最容易出现的问题都是时间控制。如前所述,不同类型的Code Review有其侧重点,所以,讨论的组织者要负责把握讨论的方向,防止发散,在Code Review的环节中,我们常说的一句话是:“线下讨论”,以此扔掉跑偏的话题。

转载自:http://dreamhead.blogbus.com/logs/216262052.html