文档过长,并未完全发表,如有需要,请点此处下载
-------------
代码评审(Code Review)是敏捷开发很重要的一环,是保证软件质量的最佳实践之一。要做好代码评审, 就需要有一套简单,高效,功能完善且界面友好的工具,来支持代码审查审查流程。
目前部门还没有采用Pair Programming那种时时刻刻都在review代码的工作方式,代码Review多采用走查方式,即代码写完后召开一个Code Review的Meeting,集中时间和经验丰富的人力对重点代码进行筛查,这种方式的代码Review有利,但也有弊。其弊端在于低效和覆盖面小。做一次走查需要N多人参与若干个小时,而在这段时间里不是每个参与者都能极其高效的参与到走查中的,实践证明只有少数几个人能真正在一次代码审查会议上起到关键的作用。另外走查一次能覆盖的代码范围又较小,一些看似不重要却很可能带来BUG的代码在走查会上很容易被遗漏。Code Collaborator 和Code Review等工具是对代码审查是一种很好的补充。Code Collaborator是一款收费工具,目前我部门ANM2000专项正在使用,效果较好。当前比较流行的开源Code Review工具有Review Board、CodeStriker等。
依据我《代码审查流程》,综合分析,备选的两款工具分别是:Code Collaborator(代码合作者)和Review board(评审委员会)。在完成两款工具的使用对比后,根据试用的实际情况对两款工具进行比较见下表:
n 【基于Code Collaborator和Reviewboard的代码审工具试用对比表】
两款工具的安装与试用说明见:
n 附件一:《基于ReivewBoard的代码审查平台搭建简要说明》
n 附件二:《基于Code Collaborator的代码审查平台搭建简要说明》
【基于Code Collaborator和Review board的代码审工具试用对比表】
要 素 | Code Collaborator解决方案 | ReviewBoard 解决方案 | |||
优点 | 缺点 | 优点 | 缺点 | ||
1.安装 | 安装简便,不易出错。 支持Windows、Linux、Max OS X、Solaris、BSD上安装。 | 收费 软件,故成本高 | 开源软件,成本低。 官方推荐在Linux和 Windows下安装 | ReivewBoard(开源工具)的安装的确有些让人头痛,一堆互相依赖的软件包,版本稍有差异就很可能导致安装运行失败。而且失败的原因还很难得知。目前安装时仍有不稳定现象出现(一般报错有两种: error1: Download error for http://www.pycrypto.org/files/pycrypto-2.3.tar.gz:<10065,'No route to host'> error2: Setup script exited with error: Python was built with Visual Studio 2003; extensions must be built with a compiler than can generate compatible binaries. Visual Studio 2003 was not found on this system.If you have Cygwin installed,you can try comiling with MingW32,by passing "-c mingw32"to setup.py.) | |
安装最后创建出来的站点的时区是默认的美国太平洋时间,而不是北京时间。尝试在站点配置页面修改时区的时候,整个站点就挂了。 | |||||
2.中文支持 | 对中文支持较好,试用期间没有发现问题 | 按照默认的步骤安装和配置后,输入和保存英文均没有问题。但是一旦输入中文,保存后页面显示的都是乱码,甚至某些时候在保存中文数据时ReivewBoard还提示错误。 | |||
3.版本控制系统 | 支持集成许多版本控制系统,包括SVN, CVS,Clearcase, Visual SourceSafe 、等。 | 一个叫做“提交审查”的工具被用来和SCM系统进行连接(当前支持SVN、CVS、Perforce、Git和Mercurial等) | |||
4.用户基础界面信息 | 1.多个同时评论 2.工作流支持评论/被许多作家在不同时区分开 3.版本控制集成 4.缺陷跟踪与严重程度,类型,分类,清单,和外部的问题跟踪器集成 5.全方面的度量指标,报告和数据出口 6.项目和角色为基础的规则和报告 7.基于Web的客户端和命令行跨平台客户端 8.命令行API的集成,扩展,自动化,并触发 | 1.在本地检出的代码的修改。 2.通过公布diff、编写描述和选择一些审查者来创建一个审查请求。 3.审查请求中点击“发布”并等待审查者看到它。 4.其他人看了你的审查请求。 5.你根据他们的评论更新了你的代码。 6.你公布了更新后的diff,以及对他们评论的解答以指明你修改了什么(或者你要说明为什么你不打算按照他们的建议修改代码)。 7.大家看了你更新后的代码,并请你继续。 8.你将修改提交到仓库中。 9.你在审查请求中点击“设置为已提交”来从其他人的面板中移除你的审查请求。 | |||
5.实时问题沟通 | 基于Web的即时“聊天”界面。 | 基于Web的即时“聊天”界面。 | |||
6.审查对象 | 不仅仅是文本文件,还可以是图片、HTML、WIKI网页、文件托管在Intranet或基于Web的文档管理系统。(测试用例也可以评) | 仅是文本文件 | |||
7.度量 | 自动收集在审查花费时间、缺陷数据(缺陷密度,和缺陷数),可定制输出审计报告 | 有数据统计,但不可定制 | |||
8.邮件 | 无问题 | ReivewBoard的Mail通知设置问题,公司采用SSL协议加密Mail, ReivewBoard仅支持TSL,在网上查了一下这两个协议应该是兼容的,但是设置后就是无法将Mail发送出去。 | |||
9.可定制的工作流程 | 可配置不同类型的审查规则。“自我检查”审查可能只要求看在他提交自己的文件。 “正式的”审查可能需要一个主持人,作家及多个审查者,并记录。可配置的角色让你可以注明每个人的期望检查和控制每个用户可以做什么和发表评论。每个用户在流程控制允许标记评论,也可以选择哪些事件将重新审查或审查相关通知更新。 | 不可定制工作流程 | |||
10.数据库支持 | 支持微软SQL Serve和Oracle数据库等。 | 支持三种数据库服务器:MySQL、PostgreSQL 、SQLite | |||
11.其 它 | 中文的学习资料还比较少 | 中文的学习资料较少; 如果有代码是在Unix GBK环境下开发的,所有源代码文件都是以GBK编码格式存储。一旦提交了这些源文件的diff,在ReivewBoard中“View Diff”时看到的中文将全是乱码,更严重的是某些时候ReivewBoard显示的代码差异的位置与真实代码修改的位置不符合。 |