揭开极端编程的神秘面纱：结对致胜
——两人智慧胜一人
作者：Roy W. Miller 本文选自：IBM developerWorks中国网站 2003年05月30日
某些 XP 实践让项目经理感到可笑，而让程序员畏缩。结对编程（或结对）就是其中一种。根据一些 XP 评论家的反馈，结对编程获得了“最可能令人不快的方法”的“奖项”— 也就是说，如果您不得不给它一个头衔的话。本月，XP 专家 Roy Miller 讨论了这种编写代码的基本方法，包括对于结对的误解、为什么那么多软件开发人员都讨厌它以及为什么它对项目的成功是如此重要。请在本文的论坛中与作者和其他读者分享您对本文的看法。（您也可以单击本文顶部或底部的“讨论”来进入论坛。）
在过去五十年里，编程基本上是一种单干的职业。哦，当然，程序员也与别人交谈，尤其在项目的需求收集阶段。但一旦开始编码，大多数公司的程序员就会一头埋进他们的办公室或隔间里独自工作。经理们并不太在意，因为程序员独自工作更易于制定工作计划，而且让许多人同时处理问题的不同部分似乎效率更高。后来出现了 XP 倡导者，他们说程序员应该结对编写代码。如果您将这种说法讲给大多数经理和程序员听，肯定会受到异样的注视，就好象他们为您的误入歧途而感到可惜。其原因就是因为他们不知道结对究竟是什么，或者他们确实知道结对，但认为这是一种不明智或疯狂的编码方法。
结对是什么 — 它不是什么
当我第一次向不熟悉结对的人提起这个概念时，我会得到三种常见的反应：
◆ 噢？
◆听起来很有趣。
◆荒唐／愚蠢／效率低下／填写您喜欢的贬义词吧。
相对于第三种反应，我能更容易地应对前两种反应，因为前两种反应通常来自于需要更多信息的人。在第一种情况中，这个人完全不知道我正在谈论的内容，因此我给他一个快速定义：
结对就是两个人一起解决同一个编程问题。
正如我在本专栏的第二篇文章“ 揭开极端编程的神秘面纱：“XP 精华”重访，第 2 部分”中所说的，结对的机制看起来如下：
［结对］通常表示两个开发人员共用一台计算机、一台监视器、一个键盘和一个鼠标（我发现两台监视器、两个键盘和两个鼠标更有趣、更高效，但一套设施也可以干得很好）。您和搭档坐在键盘前。一个人驾驶（“驾驶员”），另一个人为他导航（“导航员”或“伙伴”）。
如果驾驶员停滞不前或受到挫折或者失去了思路，导航员和驾驶员可以互换角色。实际上，这种角色互换应该经常发生，有时可能每隔几分钟（甚至更频繁）就互换一次。一旦您习惯了这种做法，并且适应了与您结对的特定人员，您就会进入这种流程，很自然地来回互换角色。
当我用这些话向说“噢？”的人描述结对时，他们的反应通常会变成“听起来很有趣”或更可能是“荒唐”。他们可能会问关于结对如何在他们的特定情况中起作用的问题（请参阅本文的论坛，您可以在其中提出这些问题，并且查看我对在您之前提出这些问题的人的回答），他们也可能要说服我这不是一个可行的选择。我稍后再讨论如何应对说“荒唐”的人，首先让我谈谈我听到的最有趣的问题：为什么要结对？
结对的好处
您为什么要结对？简单的回答是结对可以：
◆减少风险
◆使团队生产效率更高
◆生成更好的代码
风险会使大多数团队停滞不前。回想一下您的上一个项目。我敢打赌您会想起您想要做但却不敢冒险去做的一些事，这是因为您太想求稳。别人也一样。减少风险的最佳方法是确保团队中的每个人都完全熟悉系统的所有部件以及对系统的所有更改。技术讲解和设计文档很有用，但对于大多数快节奏的项目，它们并不能很好且迅速地传播知识。传播知识最有效的方法是让一个知道代码的人与不知道代码的人一起解决问题。
结对是经理和团队减少风险并防止因更改而毁掉团队必须运用的最好的工具之一。当团队成员结对时，所有设计决策和代码更改都至少由两个人完成。通过让程序员结对，经理确保了更多人熟悉代码以及它经历的更改。此外，两个人编写的代码总比一个人写的代码好。两个人的智慧确实胜过一个人的，对于影响整个系统的设计决策更是如此。无论一个程序员多么聪明（或自以为多么聪明），第二种意见有助于避免由于无知、自大或只是由于疏忽而产生错误决策。
虽然许多程序员保持专心致志可能没有问题，但是让其他人使我们这些凡夫俗子中的另一些人不出闪失当然也是有帮助的。当您尝试解决令人沮丧的问题时，这特别有帮助。当您想要放弃时，旁边有人鼓励您，让您继续前进。团队也不大可能忽略测试或其它重要的细节 — 只有这样才会增加生产力。
在我采用 XP 之前的项目中，我的团队随着项目的进展缓慢提速，但随着错误的增多最终又慢下来。但是，在 XP 项目中，我的团队很快达到难以置信的快速，而且一直保持着这个速度。例如，最近团队的速度从第一次迭代的 14 个环节点到第 5 次反复的 60 个环节点以上（请参阅参考资料以获取关于环节点的 XP 概念的更多信息）。其主要原因是我们的代码比我以前所见过的代码更成熟，而且成熟得更快，这就允许我们随着项目的发展而更快地前进。当团队成员结对时，至少有一个人一直在复查代码。这是我听说过的最好的代码复查。
XP 中简单性的价值建议我团队中的每个人应该在有效的前提下，对代码和过程采用最简单的方法。当您刚开始时，结对似乎并不简单。这会有点不舒服，需要去习惯它。但 XP 的价值、原理和实践不是鼓励您尽可能地做最简单的事情 — 它们鼓励您在有效的前提下，做最简单的事情。如果有些事情虽简单（比如，让每个人独自编码）但没有效果，那么它并不是行之有效的最简单的事情。有时，在您适应之前，行之有效的最简单的事情难以做到。结对就是一个好例子。以我的经验来看，不结对通常不如结对有效。
为什么有些程序员讨厌它
我遇到许多程序员，他们都认为结对是荒唐的举动。其中许多人都拒绝尝试它，甚至拒绝以开放的心态来讨论它。我认为他们强烈的反感来自于几个原因：
◆他们相信结对会“减缓他们的速度”。
◆他们曾尝试过结对，却发现它效率太低和／或压力太大。
◆他们需要时间来独自解决问题。
◆从更深的角度来看，他们害怕让其他人发现他们并非始终是天才。
程序员往往很自大，而且许多程序员容易变得自以为是。有时，他们可以用绝好的聪明才智和技术来虚张声势，甚至那些没有才能的人都可能认为他们很行。尽管如此，即使世界上最好的程序员也可以从最低级的黑客身上学到东西 — 这是他们中的许多人忽略的一个事实。如果程序员说结对会减慢他的速度，也许他是对的。也许与别人一起工作会减缓他个人的速度。但用两个人的智慧来解决问题的好处可以抵消个人生产力的短期下降。大多数程序员说结对会减缓他们速度时的意思是：“我比其他人更好，让他参与我的工作只会拖累我。”
结对并不适合所有人。花一整天时间在隔间里与另一个人探讨想法也许一直以来都不是您这样的典型程序员的想法，而且它可能带来压力。但是压力可以带来好处。与人交往通常比独自一人更困难，但每个程序员迟早必须与别人（或至少是其他程序员）交流，以便完成工作。结对是一种习惯，它有助于人与人之间的交流，就象编码一样，自然而并不可怕。
即使程序员接受了交流是学习和创造的更佳方式这一想法，他仍可能会感到他好象需要一些“独处时间”来解决问题。我可以理解。有时，集中精神思考问题而不必向别人讲清自己的想法是我解决手头问题时必需的。但是，我相信这种对独处时间的需求实际上是某些更深层次的症状。
在程序员解释他们为什么认为结对编程很愚蠢的所有原因中，最可怕的原因是他们害怕。这就是人。没有人想要暴露他的弱点和无知。许多程序员很难承认自己并不聪明，但他们更难以接受暴露这一点。他们讨厌可能会证明他们错了的想法。但我们需要暴露我们的弱点，以便从中吸取教训，进而获得提高。结对可以让您成为更健全的专业软件开发人员。
为什么有些经理讨厌它
我认为许多经理讨厌结对编程这个想法是由于以下原因：
◆ 条件反应
◆害怕他们的同级或上司的想法
◆为他们工作的程序员会反对
尤其在过去的一百年里，经理们已经非常习惯于相信多个人完成同一项任务从本质上说是效率低下的。在某些行业，如制造业，也许确实如此。但对于脑力工作，如软件开发，未必是这样。但是，只要有人开始讨论使程序员结对，许多经理就会说：“效率太低。”我通常会说：“没错，很对。”创建好的软件并不是一个效率优化问题。它是发明。发明是一件棘手的事情，在这一情形中，效率不起作用。现在，如果两个人坐在一起，但一个人只是看着另一个人的肩膀，而不参与工作，那效率当然低了。相反，如果两个程序员共同工作以解决同一个问题，两个全神贯注的人的想法是非常有用的。解决方案将几乎总是更好的。如果一个人灵光闪现，另一个人会通过关注该想法的最简单实现，从而起平衡作用。如果那个人过于强调简单，而将正确的想法变成了愚蠢的，那么另一个人就可以制止这种愚蠢的行为。经理在这个问题上的墨守成规是错的，而且大多数经理都没有（或者无法）对此产生疑问。
许多经理回避结对的原因之一就是他们害怕如何让别人了解结对。如果他们的老板看到几个程序员坐在一起看着同一个监视器，他也许会冲进经理的办公室，要求知道为什么浪费“资源”。如果同级经理偶尔来与您一起讨论一些事情，看到程序员都结对工作，也许会有传言说这个经理头脑发昏了。那的确令人害怕。但我认为对团队真正（相对于表面的）生产力的损害胜过对经理名誉的损害。结果会证明一切。假设他让他的程序员结对工作，而不是每个人独自工作。如果结对实验得到了比通常更好的结果，那么取得结果的方法就不再是个问题。它甚至可能会成为标准。
请注意，顺便说说，我假设该经理让他的程序员结对工作。如果程序员不想这么做，该怎么办呢？我认为，这就是大多数开发团队不进行结对工作的最大原因。我与许多认为应该进行结对的经理讨论过。但是，还是那些经理告诉我：如果强迫他们的程序员结对，这些程序员会威胁要辞职（有时会是全体辞职）。您已经知道为什么程序员会有那种反应，但经理应该怎么做呢？我认为只有三种选择：
◆寻找愿意结对的人，管理他们。
◆强迫团队（包括反对者）尝试实验性地结对工作两星期。
◆到其它有愿意在您手下进行结对工作的人的地方去。
许多人的反映是我天真得无药可救了，在被这些口水淹没之前，请允许我说：我意识到第一种选择通常不可行。大多数经理没有那么大的权力。第三种选择有点过激，但可以立即实现。但是，会证明第二种选择也许更有趣。
有些研究（虽然是利用大学生做的）显示了最初讨厌结对想法的程序员在尝试之后最终喜欢上这种方式（请参阅参考资料中由 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 编程各方面内容的大量文章。
关于作者
Roy W. Miller 从事软件开发和技术咨询工作将近十年了，最初在 Andersen Consulting（现在的 Accenture）工作，目前则在位于北卡罗莱纳州的 RoleModel Software, Inc. 工作。他使用过重量级方法和灵活方法，包括 XP。他与人合著了 Addison-Wesley XP 系列丛书中的一本（Extreme Programming Applied: Playing to Win），目前他正在撰写一本关于复杂性、紧急情况和软件开发的书（暂定标题为 Growing Software: Exploding the Myth of Prediction and Control）。请通过 rmiller@rolemodelsoft.com. 或 roy@roywmiller.com. 与 Roy 联系。您也可以通过 www.roywmiller.com. 访问他的个人网站
『转自 IBM developerWorks中国网站』
文章来源于领测软件测试网 https://www.ltesting.net/
