Adium的Peter Hosey谈代码复审

作者 Jonathan Allen 译者 郭晓刚 发布于 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

译者 郭晓刚 是InfoQ中文站架构社区编辑，创建并终结过数家软件小企业，翻译过多本技术书籍。

• 更早的 >