结对编程与代码评审

转载于http://blog.csdn.net/happydeer/article/details/8721752

Tom Dommett对“结对编程”（Pair Programming）有一些正面的经验。他把它们写下来，并分享给大家了：

这个概念是要让两个开发者在同一台机器上工作。他们都有各自的键盘和鼠标。在任何一个给定的时间，其中一个人作为“驾驶员”而另一个作为“领航员”。这两个角色每隔一段时间（可以是一小时，也可能是任意时候）交换一次。“驾驶员”负责编写代码，“领航员”则负责阅读、核对、拼写检查以及在脑子里测试代码，同时思考当前碰到的问题以及接下来的任务。如果“驾驶员”遇到了问题，那么有两个人来一起寻找解决方案，而且通常情况下其中一个人总会想出来好点子。

其他的好处还包括，两个人总是有不同的专长，而这些技能是可以传递的。当一个人向另一个人展示一些技巧、精妙的变通方案等等的时候，实际上他们是在进行临时的培训。

最终的结果是，两个开发者都完全了解代码——代码是如何工作的，以及为什么它们是这样设计的。很有可能这种工作方式下产生的代码比一个开发者单独完成的要好，因为毕竟旁边有个人在看着呢……代码中包含错误或者勉强的拼凑以及那些将来可能造成维护问题的东西的可能性会小很多。

如果团队大一点的话，结对的组合还可以每周变换一次，这样每个团队成员都有机会和不同的人结成伙伴。这会带来巨大的好处，因为它可以让开发者们交谈，并且用代码这个通用语言来交换想法。

我们发现，结对编程的效率跟单独工作一样快。代码被更快地完成，而且不需要返工。当代码确实需要改动的时候，有不止一个人熟悉代码。

这是一个令人鼓舞的结果。任何可以让团队更好交流的做法，我都会为之鼓掌。

结对编程这个想法使我很好奇，但我个人从来没有经历过这种工作方式。然而，我的确很享受和其他开发者一起工作。每当我挨着一个开发伙伴坐下来跟他一起工作的时候，我总能从他们身上学到一些诀窍和技术。这样参与的双方都可以快速地学习。不过，我跟他们坐在一起的时间并不长。我对花上整整8小时这样工作稍许有些担心。我怀疑长时间这样工作可能会使人疲劳，除非你在选择你的编程伙伴上非常地幸运。

我曾经讨论过“代码评审”（CodeReview）的功效。那是我亲身经历过的，因此我可以毫无保留地担保代码评审的价值。我忍不住想知道，是否结对编程就是打过兴奋剂的代码评审。它们之间不是一个替代另一个的关系——你当然可以两个都做——但是，我怀疑结对编程的很多好处都可以通过可靠的同级评审（PeerReview）来获得。

不过，代码评审也不是万能灵药，就像MartyFried指出的那样：

我对于代码复查的经验好坏参半。其中的一个问题是，似乎没有人愿意花时间去真正理解那些并不简单的新代码，所以反馈通常是非常笼统的。但是后来，当有人要在原有代码基础上添加功能或者修改错误的时候，他们通常会有很多的反馈（有时候他们还会怒气冲冲地想要推倒重来），但那时候可能已经太晚了，而且效果也不会理想；之前写那块代码的程序员可能也已经不在了。我觉得，代码评审或许多多少少有些好处，但要让一个程序员告诉他的老板他的程序员同伴工作很差劲就有点勉为其难了。

结对编程的优势就在于它的即时性：当复查者就坐在你边上的时候，忽略他是不可能的。大多数人在可以选择的情况下都会选择息事宁人。然而在结对编程中，这是不可能的。在代码被写下来的那一时刻，配对的每个人都必须立即理解代码。结对或许有点唐突，但是它能强制一定程度的交流，这是你用其他方法可能永远也做不到的。

另一方面，相比于把程序员的身体堆在同一个地方（这是结对编程的要求），同级评审更有灵活性（其规模可大可小）。让我们来看一看Macadamian在WINE项目中做代码评审的经历吧：

译者注：WINE（Wine Is Not an Emulator，即Wine不仅仅是一个模拟器）是一款优秀的Linux系统平台上的模拟器软件，用来将Windows应用软件运行到Linux平台上。该软件更新频繁，日臻完善，可以运行许多大型的Windows系统下的软件。另外，英语单词wine是葡萄酒的意思。

在WINE项目中，我们采用了两个以前我们不曾用过的流程：公开的同级评审——在这个流程中，新的代码和补丁会通过一个邮件列表发送给所有参与这个项目的人；以及单一提交者——在这个流程中，项目主管对哪个补丁能被接受进入源码树有最终的决定权。

我们很快发现，Alexandre Julliard对于代码能否进入源码树特别地挑剔——他自1994年开始就已经是WINE的维护者以及核心开发者之一了。我们团队的补丁都要经过他的仔细审查。当其中有些被驳回的时候，团队里就会有很多的抱怨：“我的代码能正常工作。这个家伙以为他是谁啊？最后期限就要到了，我们没时间了!”但是，随着项目的进展，我们意识到我们在开发有史以来最好的代码。我们写出了整洁、设计良好的代码，并且能在第一遍就通过审核进入源码树很快就成为了一种骄傲。我们同时还发现，尽管这个项目十分庞大，并且开发者散布在世界各地，我们仍然非常清楚地知道整个项目的进展状况，因为我们在邮件列表上看到了每一个补丁。我们现在在每个项目上都采用代码评审；在更大型的项目上，我们还会创建一个内部邮件列表，并且指定一位单一提交者。或许在你的公司里建立起代码评审的流程会很痛苦，而且团队里可能还会有些抱怨，但是在代码的质量以及可维护性方面你将会看到巨大的进步。

我认为这两种方法很明显都是“纯好事”，尽管它们都有各自的优点和不足。其中的一个就一定比另一个更有效吗？我们应该两个都做吗？

归根结底，我不认为这是一个二选一的问题，只要保证你有超过一双的眼睛在看你所写的代码，不管你选择用哪种方法都是可以的。当你的代码有其他人帮你复查的时候——不管那个人就坐在你边上，还是远在几千英里以外——你就会开发出更好的软件。这个我可以保证！。