程序员往往很自大，而且许多程序员容易变得自以为是。有时，他们可以用绝好的聪明才智和技术来虚张声势，甚至那些没有才能的人都可能认为他们很行。尽管如此，即使世界上最好的程序员也可以从最低级的黑客身上学到东西 — 这是他们中的许多人忽略的一个事实。如果程序员说结对会减慢他的速度，也许他是对的。也许与别人一起工作会减缓他个人的速度。但用两个人的智慧来解决问题的好处可以抵消个人生产力的短期下降。大多数程序员说结对会减缓他们速度时的意思是：“我比其他人更好，让他参与我的工作只会拖累我。”

　　结对并不适合所有人。花一整天时间在隔间里与另一个人探讨想法也许一直以来都不是您这样的典型程序员的想法，而且它可能带来压力。但是压力可以带来好处。与人交往通常比独自一人更困难，但每个程序员迟早必须与别人（或至少是其他程序员）交流，以便完成工作。结对是一种习惯，它有助于人与人之间的交流，就象编码一样，自然而并不可怕。

　　即使程序员接受了交流是学习和创造的更佳方式这一想法，他仍可能会感到他好象需要一些“独处时间”来解决问题。我可以理解。有时，集中精神思考问题而不必向别人讲清自己的想法是我解决手头问题时必需的。但是，我相信这种对独处时间的需求实际上是某些更深层次的症状。

　　在程序员解释他们为什么认为结对编程很愚蠢的所有原因中，最可怕的原因是他们害怕。这就是人。没有人想要暴露他的弱点和无知。许多程序员很难承认自己并不聪明，但他们更难以接受暴露这一点。他们讨厌可能会证明他们错了的想法。但我们需要暴露我们的弱点，以便从中吸取教训，进而获得提高。结对可以让您成为更健全的专业软件开发人员。

　　为什么有些经理讨厌它

　　我认为许多经理讨厌结对编程这个想法是由于以下原因：

　　◆ 条件反应

　　◆害怕他们的同级或上司的想法

　　◆为他们工作的程序员会反对

　　尤其在过去的一百年里，经理们已经非常习惯于相信多个人完成同一项任务从本质上说是效率低下的。在某些行业，如制造业，也许确实如此。但对于脑力工作，如软件开发，未必是这样。但是，只要有人开始讨论使程序员结对，许多经理就会说：“效率太低。”我通常会说：“没错，很对。”创建好的软件并不是一个效率优化问题。它是发明。发明是一件棘手的事情，在这一情形中，效率不起作用。现在，如果两个人坐在一起，但一个人只是看着另一个人的肩膀，而不参与工作，那效率当然低了。相反，如果两个程序员共同工作以解决同一个问题，两个全神贯注的人的想法是非常有用的。解决方案将几乎总是更好的。如果一个人灵光闪现，另一个人会通过关注该想法的最简单实现，从而起平衡作用。如果那个人过于强调简单，而将正确的想法变成了愚蠢的，那么另一个人就可以制止这种愚蠢的行为。经理在这个问题上的墨守成规是错的，而且大多数经理都没有（或者无法）对此产生疑问。

　　许多经理回避结对的原因之一就是他们害怕如何让别人了解结对。如果他们的老板看到几个程序员坐在一起看着同一个监视器，他也许会冲进经理的办公室，要求知道为什么浪费“资源”。如果同级经理偶尔来与您一起讨论一些事情，看到程序员都结对工作，也许会有传言说这个经理头脑发昏了。那的确令人害怕。但我认为对团队真正（相对于表面的）生产力的损害胜过对经理名誉的损害。结果会证明一切。假设他让他的程序员结对工作，而不是每个人独自工作。如果结对实验得到了比通常更好的结果，那么取得结果的方法就不再是个问题。它甚至可能会成为标准。

　　请注意，顺便说说，我假设该经理让他的程序员结对工作。如果程序员不想这么做，该怎么办呢？我认为，这就是大多数开发团队不进行结对工作的最大原因。我与许多认为应该进行结对的经理讨论过。但是，还是那些经理告诉我：如果强迫他们的程序员结对，这些程序员会威胁要辞职（有时会是全体辞职）。您已经知道为什么程序员会有那种反应，但经理应该怎么做呢？我认为只有三种选择：

　　◆寻找愿意结对的人，管理他们。

　　◆强迫团队（包括反对者）尝试实验性地结对工作两星期。

　　◆到其它有愿意在您手下进行结对工作的人的地方去。

　　许多人的反映是我天真得无药可救了，在被这些口水淹没之前，请允许我说：我意识到第一种选择通常不可行。大多数经理没有那么大的权力。第三种选择有点过激，但可以立即实现。但是，会证明第二种选择也许更有趣。

　　有些研究（虽然是利用大学生做的）显示了最初讨厌结对想法的程序员在尝试之后最终喜欢上这种方式（请参阅参考资料中由 Alistair Cockburn 和 Laurie Williams 撰写的 The Costs and Benefits of Pair Programming 以获取更多详细信息）。强迫人们做一些事是不明智的，但有时打破人们关于其集体或个人意识陈规是必要的。试着强迫人们花很短的时间来尝试结对工作。如果他们反对，对他们强调只执行两周。在两周内，任何人都可以忍受做任何事。那些在两周后仍没有被说服的人在两个月后也不会被说服 — 而即使他们会信服，您可能也永远看不出来，因为他们决不会尝试结对工作两个月。经理的最大愿望是两周时间可以让大多数程序员相信结对工作的前景光明。如果不能做到，那么您永远只能有第一种和第三种选择。

　　一个好经理不会强迫执行结对工作很长时间。那就不只是不明智了。这很危险。这很容易树敌。如果您的程序员都很生气而要辞职，那么您就要独自承担责任。进行实验是有益的。最好在一些团队成员接受之后再做改变。压迫通常会失败。

　　告诉我您的想法

　　您可以帮助我确定下个月要写什么。您对 XP 最大的疑问是什么？您认为什么是十分愚蠢的、不明智的、不专业的或不可行的？什么是最让您困惑的方法？请在本专栏的论坛中提出您的建议。

　　结对究竟是什么

　　可以从两个层面讨论结对。第一层是机制 — 关于什么构成了“结对”的原始描述。第二层，也就是更深入的一层是人与人之间的。结对是您与团队中的成员一起工作。那是工作中最具挑战性的部分 — 与您未曾打过交道的人合作，只是因为（通常）别人告诉您必须这么做。因为每个人都是少有的，所以无论是对您还是对对方，这可能是一个挑战，。正如 Ken Auer 和我在 Extreme Programming Applied（请参阅参考资料）中指出的，人际关系是很难处理的，尤其是在政策和隐藏的操作规程可能使事情复杂化的职业环境中。即使只是几个小时，这些类型的关系都不是大多数人感兴趣的事。这是一个极端想法，不是人人都这么想。但它也可以对您的职业生涯产生一些最有益的经验。

　　参考资料

　　请阅读 Alistair Cockburn 和 Laurie Williams 撰写的 The Costs and Benefits of Pair Programming（XP2000 建议，2000 年）中关于结对编程的经济效益的内容。

　　请阅读 Laurie Williams 和 Robert Kessler 撰写的 Pair Programming Illuminated（由 Addison-Wesley 于 2002 年出版）以获取关于结对的更理论性（和实际）的讨论。

　　Ken Auer 和 Roy Miller 合著的 Extreme Programming Applied: Playing to Win（由 Addison-Wesley 于 2001 年出版）提供了关于如何应用 XP 的更多讨论。

　　整个 Demystifying Extreme Programming 系列提供了对 XP 方法的深入研究（其中有一些个人观点）。文章“揭开极端编程的神秘面纱：关注价值”（2003 年 2 月）详细讨论了环节点和它们对项目团队意味什么，“揭开极端编程的神秘面纱：“XP 精华”重访，第 2 部分”（2002 年 9 月）讨论了结对编程的机制。

　　在“Extreme Programming with IBM VisualAge for Java”（developerWorks，2001 年 4 月）中，了解 VisualAge for Java 为什么是 XP 团队的优秀工具。

　　有关可以支持 XP 团队的其它工具，请阅读“Excerpt from Java Tools for Extreme Programming”（developerWorks，2002 年 7 月）。

　　在 developerWorks Java 技术专区中可以找到关于 Java 编程各方面内容的大量文章。