[Z] 结对编程

作者:asky 日期:2006-07-24

字体大小: 小中大

在 XP 中，所有的生产代码都是由结对的开发者编写的。大多数开发者都从不曾有过与另一个人一起实际编写代码的经历，刚开始会感到有点不习惯。结对编程通常意味着两名开发者共享一台计算机。一个人键入代码（“司机”（driver）），另一个人帮他指路（“领航员”（navigator）或称“伙伴”（partner））。如果司机被困住了（或失败了），或者如果领航员有一个好主意但不通过键盘输入就不能很好地描述，那么当前的司机可以放弃控制权，做一会儿领航员。每个人都应该经常切换角色。一旦您习惯了这些角色，来回切换就会相当轻松。

这种方法听起来好象效率不高。我一直很喜欢 Martin Fowler 的回答：“当人们说结对编程会降低工作效率时，我回答说，'如果编程最耗时间的部分是打字，那么这是对的。'”实际上，结对编程或者简称“结对”，可以提供许多好处，包括：

所有的设计决定都用了至少两个人的智慧。
至少有两个人熟悉系统的每一部分。
两个人都忽略测试或其它任务的可能性更小。
改变各对的组合可以在团队范围内传播知识
代码通常至少被一个人复查。
实验法研究指出代码复查可以提高代码的质量，但是我讨厌那样做。我还认为要正确地进行复查将非常困难，复查工作没有结对编程那么有效。如果每行生产代码都被一个对代码的意图非常熟悉的人复查过会怎样？结对编程为您提供的刚好就是这一点。只有真正参与才能足够忠实。

Alistair Cockburn 与 Laurie Williams 合写的 The Costs and Benefits of Pair Programming（请参阅参考资料）中讨论的研究也表明结对编程实际上要比单独编程效率高。这与我们的直觉有点不一样。大多数管理人员（我曾经是其中之一）将看到两个开发者做一个开发者的工作，然后就看不出更多的东西了。这不是理性的思维方式。这种想法过于简单。这也是错误的。

至于风险，请考虑一会儿项目为什么会失败。其中一个主要的原因就是太依赖个人英雄。如果承担项目的英雄意外阵亡，那么您的项目可能就完了。结对的本质是要散播知识。结对的两个人应该经常切换角色。如果结对的两个人的角色都很固定，他们就会被困住。

尽管有不少人推崇结对，也有很多强有力的观点来证明结对，但大多数开发者仍讨厌这种思想。或许这是自尊心的问题。我相信，大多数开发者在内心深处都想当英雄。结对使得这一点几乎不可能实现。就象我在 Extreme Programming Applied: Playing to Win（请参阅参考资料）中所写的那样：

每个人都可以坐在其他人的旁边，并时常不经邀请就发表一些意见。许多人可以完全投入并尽力使结果更好。但真正理解结对的人知道那意味着要去喜欢另一个人。

就象我在那本书中所说的那样，我讨论的那种爱是通过行动表现出来的，不是浪漫的那种。如果您爱另一个人，您就会尽力去发现他的优点，并帮助他成长。您将是耐心的、亲切的、不嫉妒、大方的、谦逊的且有礼貌的。这种热情的人与人之间的关系，即使是只几个小时，大多数人也不感兴趣，而开发者毕竟也是人。这是一种激进的思想，并不适合每个人。但它也可以为您的职业生涯带来最有益的经历。