[原]强制 code review:reviewboard+svn 的方案

标签: | 发表时间:2011-12-29 10:05 | 作者:lanphaday
分享到:
出处:http://blog.csdn.net/lanphaday
赖勇浩( http://laiyonghao.com
我们团队在开发《天下盛境》项目的时候,制定和执行了比较好的 code review 策略,总结下来有几个优点:一是代码风格可控,代码质量有一定提升;二是新员工入职后能够得到更多人的指导,成长非常快;三是小 bug 频出的情况比我做《天》之前的项目少了至少一个数量组。当时我们的 code review 策略是这样的:
  1. 使用 reviewboard 作为工具,通过 SVN hooks 强制每一次签入都是经过 review 的;
  2. 至少要有 2 个团队成员 ship it,才能够签入。
  3. ship it 的成员中,至少有一个是资深的团队成员。
code review 是如此的有效,以至于我经常向朋友推荐,有一些朋友使用之后,觉得把 reviewboard 跟 SVN 结果起来还是蛮有挑战的,主要是编写 SVN hooks 还是需要学习不少东西,所以基本上他们都放弃了。今天我把 reviewboard-svn-hooks 项目修改、发布出来,方便大家使用。

安装

因为项目已经提交到 pypi( http://pypi.python.org/pypi/reviewboard-svn-hooks),所以简单地在命令行执行:
easy_install reviewboard-svn-hooks
就可以安装成功了,安装时,可能需要管理员权限(linux/windows都可能需要)。

配置

安装后,需要对 reviewboard-svn-hook 项目进行配置。根据操作系统的不同,存储配置文件的目录也是不同的。在 linux 系统下,它的位置是在 /etc 下,在 windows 系统下,它的位置在 %ALLUSERSPROFILE% 目录下(具体指哪个目录,请参考 http://en.wikipedia.org/wiki/Environment_variable#Default_Values_on_Microsoft_Windows)。在本文中,以 $CONFDIR 指代之。打开 $CONFDIR/reviewboard-svn-hooks/conf.ini 文件,解释如下:
[common]
# 是否记录 debugging 输出,0 为不输出,其它值为输出
debug = 0

[reviewboard]
# reviewboard 的网址
url=
# reviewboard 的用户名密码,这样才能够通过 http API 访问到 reviewboard 中的 review request 的状态
username=
password=

[rule]
# 最少需要有几个 ship it
min_ship_it_count =
# 最少需要有几个专家 ship it
min_expert_ship_it_count =
# 专家的 reviewboard 用户名,使用半角逗号分格
experts =

SVN hooks 配置

假定你的 SVN 仓库目录的 $REPOS,并且人来没有设置过 SVN hooks。打开 $REPOS/hooks 目录,把 pre-commit.tmpl 改名为 pre-commit,如果是 linux 系统,记得加上执行权限。
用文本编辑器打开 pre-commit 文件,把里面的内容全部删除掉,替换为下列内容:
REPOS="$1"
TXN="$2"
strict_review $REPOS $TXN
exit $?
至此,配置就完成了。如果你之前已经配置过 pre-commit,请参考上述脚本自己想办法调用 strict_review 应用程序。

与已经使用过的 reviewboard 集成

如果你之前已经使用 reviewboard 做过若干次 code review,那么你还有一步工作需要做:把之前使用过的 review request id 废掉。首先请找出并记下你们使用过的最大的 review request id,然后在命令行执行如下命令:
init_used_rid_db CONFDIR/rb-svn-hooks-used-rid.db MAX_REQ_ID
其中 CONFDIR 的值在上文已经提到,MAX_REQ_ID 就是前面说的使用过的最大的 review request id。

其它

最后,如果在使用中有任何问题,请到 http://code.google.com/p/reviewboard-svn-hooks/issues/list 提 issue 告诉我。
作者:lanphaday 发表于2011-12-29 18:05:35 原文链接
阅读:51 评论:0 查看评论

相关 [code review reviewboard] 推荐:

[原]强制 code review:reviewboard+svn 的方案

- - 赖勇浩的编程私伙局
赖勇浩( http://laiyonghao.com). 我们团队在开发《天下盛境》项目的时候,制定和执行了比较好的 code review 策略,总结下来有几个优点:一是代码风格可控,代码质量有一定提升;二是新员工入职后能够得到更多人的指导,成长非常快;三是小 bug 频出的情况比我做《天》之前的项目少了至少一个数量组.

聊聊Code Review

- - 梦想风暴
hopesfish评论《 那一点的调用》时,问了一个关于Code Review的问题:. 想请教一下,TW的筒子是如何做code reivew或者鼓励客户做code review的. 我在翻阅博主的帖子的时候,似乎对这块没有特别强调,而是更多偏重于TDD,我觉得TDD的问题是一碰到没有责任心的程序猿,就很容易流于形式了.

Java Code Review清单

- - ImportNew
使用可以表达实际意图(Intention-Revealing)的名称. DRY(Don’t Repeat Yourself)原则,(拒绝重复). 用代码来解释自己的做法(译者注:即代码注释). *参考自: http://techbus.safaribooksonline.com/book/software-engineering-and-development/agile-development/9780136083238.

我的code review规则

- vento - 我的宝贝孙秀楠 ﹣C++, Lua, 大连,程序员
1) 是否有语法错误,编译错误,编译警告. 做法:下载最新代码,将编译警告级别提升到最高,检查output信息. 2)是否符合需求,完成requirement文档要求的内容,不能多,也不能少. 注意:即使发现有问题代码,如果与需求关联不大,不要涉及. 应该让每次enhancement和bug fix最简洁,牵涉范围最小,影响到组件最少.

Code Review那些事儿

- - 非技术 - ITeye博客
       曾经有一段 垃圾代码放在我的面前,我没有拒绝,等我真正开始接手的时候我才后悔莫及,程序员最痛苦的事莫过于此. ---------改编于周星星的经典台词.       虽然有点夸张,但编码界确实大大存在这种情况,每当接手别人的代码,都有一种想重新写一遍的感觉,等到别人再来接手你的代码时,同样的感觉.

代码审查(Code Review)清单

- - 博客 - 伯乐在线
代码审查可以帮助提高代码质量,避免由于代码习惯而造成的 bug. 下面列出的这些要点因该可以作为大部分代码审查的指导,如果是 Java 应用的话,这些建议应该被视作最佳实践. Javadoc 应该在每一个类和方法中添加. 如果是修复某个 bug,应该添加 bug ID. 走捷径的方法或者复杂的逻辑要有解释.

从Code Review 谈如何做技术

- - 酷 壳 - CoolShell.cn
(这篇文章缘由我的微博,我想多说一些,有些杂乱,想到哪写到哪). 这两天,在微博上表达了一下Code Review的重要性. 因为翻看了阿里内部的Review Board上的记录,从上面发现Code Review做得好的是一些比较偏技术的团队,而偏业务的技术团队基本上没有看到Code Review的记录.

测试技术中CODE REVIEW的重要性

- - CSDN博客推荐文章
        [近期关注App自动化测试,欢迎交流,本博客文章版权归作者所有,转载请联系]     .         最近有网上的朋友向我咨询作为测试员是否应该跳槽,   首先我觉得应该向大家介绍一下什么是测试工程师,  什么是测试员,   在国内的一些中型企业并没有特别的指明.   这里测试工程师主要指测试开发工程师, 主要包括两类,  其一是测试软件开发的工程师,  其二是自动化测试脚本开发和维护的工程师,   而测试员主要指单纯编写/管理测试用例,  或是手工测试人员, 一些国内的大中型网络视频公司仍然在用纯手工测试,我感觉到很汗颜.

Clean-Code: 注释

- We_Get - 博客园-首页原创精华区
别给糟糕的代码加注释-----------------重新写吧. 这是书中的关于注释一章的第一句话,怎么说呢,这句话个人感觉很对,但是实际上却很少这么做,. 糟糕的代码不是自己写的,别人写的代码,还是让别人自己去维护吧,出了问题也是别人的. 糟糕的代码目前可以正常工作,软件开发中有一条古老哲言:如果它能工作就不要动它,很多程序员都遵守这条准则.