BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

Adium的Peter Hosey谈代码复审

| 作者 Jonathan Allen 关注 553 他的粉丝 ,译者 郭晓刚 关注 0 他的粉丝 发布于 2007年10月12日. 估计阅读时间: 6 分钟 | 如何结合区块链技术,帮助企业降本增效?让我们深度了解几个成功的案例。

无疑规范的代码复审可以捕获错误,并推迟似乎所有成功项目最终都逃脱不了的“大泥球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

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT