17611538698
webmaster@21cto.com

谈一下我们是如何开展code review的

资讯 0 5140 2017-04-27 12:01:12
代码审查的阻力[*]代码审查的重要性[/*][*]我们是如何开展代码审查的[/*][/list] 
正文
众所周知,代码审查是软件开发过程中十分重要的环节,楼主结合自己的实际工作经验,和大家分享一下在实际工作中代码审查是如何开展的,

笔者水平有限,若有错误和纰漏,还请大家指正。

回到顶部回到顶部回到顶部[h1]我们是如何开展代码审查的[/h1]
好了。罗嗦了半天。下面开始说一下在楼主参与的项目中是如果开展code review的。

第一家公司,是一家国内的大公司,就不说名字了,我所在的部门开发的产品众多,换项目很频繁,我参与的有3,4个吧,开发流程不规范,部门老大没有对代码审查有硬性要求。但带我的老师,也是项目经理(但是主要做技术,所以也可以说是技术经理)是一个非常热衷于技术的人,应该说明白代码review的重要性,我们敏捷团队有4个开发,每次写完代码后,都会进行team review。把代码投到大屏幕上,然后老师带我们去review代码。印象深刻的一次是一个同事着急回家过年,草草把代码就提交走人了,被师傅挑出来很多问题。换了项目和项目经理之后,代码review就不了了之了。

第二家公司,是一个外企,有几十年的历史了,开发流程算是比较规范了,而且分工明确。在这家公司我们的大老板(也就是技术经理的上司)对代码review是有要求的,下面详细说明我们的代码审查是如何一步一步演进的。

  • 第一阶段   team review + TFVC

先简单介绍下我们的版本控制工具:微软的TFVC,代码的branch是按如下图创建的,有一个main branch每个scrum team一个branch,出release之前把各个team的branch merge回main,最后出release branch,release branch上修复的bug也要最终回main。                                      


 

开始的时候我们是没有peer review的,每两周开一次team review。一个主持人,负责预定会议室,操作visual studio查看最近两周提交的changeset,一个记录员,负责记录发现的问题,相关功能的开发人员负责讲解和解答疑问。最后记录员将review结果记录到wiki中并发送到整个开发部门。

  • 第二阶段 自律TFVC + peer review + team review

 记不太清是从哪个visual studio版本开始支持code review了,好像是VS2012。在提交之前每个开发人员需要将代码提交给至少一个人进行review,然后生成一个code review的work item。你需要将这个work item链接到你的changeset中才能check in代码,不然我们公司自定义的policy会发出警告。这些警告是可以被忽略的,然后也能强制提交。前面说过部分老大对code review是很重视的,如何才能检查peer review的结果呢?对,将这些code review的work item数据进行查询,将没有链接work item的changeset过滤出来,然后将结果显示。技术经理和老大一眼就能看到谁没有遵守这个流程。尽管这么做了,开始执行的时候还是有不少的人出现在查询结果中。

说一下自律的问题,公司添加这个查询review结果的措施是手段,只是在某种程度上保证了流程,但目的是什么?目的是需要收到review请求的成员认认真真的review代码,而不是随便的走一下流程就OK。如果你认识到review的重要性,你可能会用心一点吧。

我们的team review 会议依然在进行,和peer review的区别就是peer review只给一个人或者少数的人进行review,而team review 是在整个scrum team间进行。

  • 第三阶段 GIT + peer review + team review

我们的公司虽然历史悠久,但对一些流程的工具和技术还是极力推崇的。大家都知道GIT是非常流行的版本控制工具,visual studio 2012也开始支持GIT,我们也一步一步的 将source code移到了TFS-GIT中。

和TFVC相比,GIT的branch是非常轻量级的,你可以很容易并且快速的创建一个branch。所以我们现在可以将branch进行细分了。TFVC和GIT的代码提交也不一样,TFVC是集中式的,最全的代码放在server上,你需要一个branch的code时要将其check out到本地。每次提交都是把代码从local一次性merge到server,如果出现conflicts,你需要在本地处理然后check in。GIT是分布式的,每个人clone的时候都会把所有分支download到本地,代码提交是通过pull request来进行的,也就是通过branch之间的merge来进行,这一点刚从TFVC转到GIT的时候很难理解。这样就得为每个人创建一个临时branch,注意这个branch在本地和server端同时存在,我们用这个branch开发自己的代码并用这个branch进行merge code。这里的pull request就相当于TFVC中的code review,TFVC你还可以偷懒忽略code review的work item,在这里就是强制性的了,没有pull request,别人不会approve你的代码,你根本就没有方法将你的代码merge到feature branch中。

还有team review会议也是照常进行的。 

评论