Adium 的 Peter Hosey 谈代码复审

阅读数:261 2007 年 10 月 11 日

话题:敏捷文化 & 方法

无疑规范的代码复审可以捕获错误,并推迟似乎所有成功项目最终都逃脱不了的“大泥球big ball of mud)”宿命。然而,每次提交代码都得安排一次会议的做法,除了最要紧的项目,很快就会坚持不下去。Peter Hosey 讲述了他在 Adium 指导代码复审的经验。

谢谢你抽空跟我们讨论这个问题,Peter。首先,你可以给我们讲一下 Adium 的背景吗?

Adium是 Mac OS X 上的一个自由的开源多协议即时消息客户端。它支持 AIM、MSN、Yahoo!、Jabber(包括 Google Talk IM、LiveJournal 和 Gizmo IM)、ICQ、Bonjour、MySpace IM,以及其他好几种。它只能在 Mac 上运行(用 Cocoa 编写),采用 GPL 许可协议。

我们几乎所有支持的协议都是用 libpurple 来实现的,它是由 Pidgin 项目开发的一个 GPL 即时消息库。

你出于什么原因开始为每次代码提交都进行代码复审?

有两件事:

(1)代码中的错误

在差不多一年前,我偶然发现了代码里的一些错误,让我直摇头说“怎么会发生这种事?!”

有些错误让我觉得说“要是当初有些测试就好了,这种错早就会被抓出来了”。

我在这个项目里并不是很活跃,不过有时候别的开发者会让我看看一个待解决的问题(因此我在好奇心的驱使下有时也会自己去追踪问题所在),或者源码中一些诡异的片段。于是我就会注意到一些错误,觉得说“等一下……怎么搞的?”。

(显然,这是见识各种错误的好方法,因为一段完美运行的代码大家不太可能会请同事来帮忙看看。)渐渐地,我受不了这些错误了,决定彻底地杜绝它们。

我订阅了提交列表,这样我就可以在他们提交的时候抓出代码里的错误。当我发现一个错误,我就直接回复给作者,指出错误的本质,通常还会建议改正的方法。用这种方法我已经找出了一些错误。

(2)Google 代码之夏

我在真正订阅提交列表之前打算了有一段时间。让我真正开始行动的原因,是我在“2007 Google 代码之夏”再次担任了指导老师。

去年我代码复审做得不够,一直拖到最终评价的时候才做;结果是我那些可怜的学生的虚拟桌面一下子堆满了代码复审意见。学生写的代码里面有很多错误我应该早就指出来,如果我开始就进行复审(听起来耳熟吧?)。

所以今年,我决心不再把事情推到活动结束的时候。我在活动一开始就订阅了提交列表,这样我的学生一提交我就可以看到他们的代码。

这个办法跟我想的一样有用,还顺便可以检查其他人的提交。

似乎你做得很顺利。你用什么源码控制软件?

Subversion。

Pidgin* 用 Monotone,他们的开发者(特别是其中一位)打算让我们即使不用 Monotone,也至少掌握一点 DVCS。我被勾引了,打算最近就试试 Monotone。虽然我这样说,但 Adium 项目现在还没有讨论过这个问题,也没有放弃 SVN 的正式计划。

我要确定的一件事是 MTN 对代码提交的邮件列表有什么样的支持。

* Pidgin 可以说是我们的姊妹项目:他们开发 libpurple,这个库实现了 Adium 支持的几乎所有协议,我们也用了这个库来支持那些协议。Libpurple 也是 Pidgin(还用说)和 Finch 的核心。

要订阅提交列表有多难?

很容易。只不过是一个 Mailman 邮件列表,它靠一个提交挂钩程序来产生邮件(一般是 post-commit 挂钩程序)。

因此订阅的手续和任何其他 Mailman 列表是一样的:可以通过 Web 界面也可以给订阅地址发邮件。

按照你目前的经验,你认为什么样的项目最适合和最不适合这种做法?

我建议任何开源项目的所有开发者都订阅提交列表。实际上,对闭源项目也是可行的;唯一的差别是邮件列表要对公众不可见。

如果你没有提交列表,但有 Trac,你可以用一个只包括提交的时间线 Feed。URL 如下:

TRAC_URL_HERE/timeline?daysback=7&changeset=on&format=rss

例如:

http://trac.adiumx.com/timeline?daysback=7&changeset=on&format=rss

当然,还可以订阅 ticket:

TRAC_URL_HERE/timeline?



&daysback=7&ticket=on&ticket_details=on&changeset=on&format=rss

不过对某些项目来说,只靠几个开发者来处理可能工作量太大了。基本上,如果你的项目很有人气,而 Trac 又允许用户自己提交 ticket(像 Adium 就是),你可能最好把 ticket 的管理安排给一些非开发者,让大多数(但不是所有)开发者只处理提交(Adium 就这样做)。

另外,我有个新想法还没试验过,也没见别人试过:如果你有一个经常提交补丁的作者,正考虑让他成为项目中正式的开发者,你可以试一下让他订阅提交列表并审核提交。如果他能够很好地找出错误(可能还写出补丁来修复错误),你就能够更加确信他适合加入你的团队。

如果你准备这样做,我还建议让这位见习开发者直接跟犯错的提交者联系,而不必按照一般的补丁过程。这样提交列表可以帮助见习开发者更好地融入现在的团队,而不仅仅是成为一个补丁来源。

查看英文原文:Peter Hosey of Adium on Code Reviews