【IT168 技术文章】

    某些 XP 实践让项目经理感到可笑，而让程序员畏缩。结对编程（或结对）就是其中一种。根据一些 XP 评论家的反馈，结对编程获得了“最可能令人不快的方法”的“奖项”— 也就是说，如果您不得不给它一个头衔的话。本月，XP 专家 Roy Miller 讨论了这种编写代码的基本方法，包括对于结对的误解、为什么那么多软件开发人员都讨厌它以及为什么它对项目的成功是如此重要。请在本文的论坛中与作者和其他读者分享您对本文的看法。（您也可以单击本文顶部或底部的“讨论”来进入论坛。）

　　在过去五十年里，编程基本上是一种单干的职业。哦，当然，程序员也与别人交谈，尤其在项目的需求收集阶段。但一旦开始编码，大多数公司的程序员就会一头埋进他们的办公室或隔间里独自工作。经理们并不太在意，因为程序员独自工作更易于制定工作计划，而且让许多人同时处理问题的不同部分似乎效率更高。后来出现了 XP 倡导者，他们说程序员应该结对编写代码。如果您将这种说法讲给大多数经理和程序员听，肯定会受到异样的注视，就好象他们为您的误入歧途而感到可惜。其原因就是因为他们不知道结对究竟是什么，或者他们确实知道结对，但认为这是一种不明智或疯狂的编码方法。

　　结对是什么 — 它不是什么

　　当我第一次向不熟悉结对的人提起这个概念时，我会得到三种常见的反应：

　　◆ 噢？

　　◆听起来很有趣。

　　◆荒唐／愚蠢／效率低下／填写您喜欢的贬义词吧。

　　相对于第三种反应，我能更容易地应对前两种反应，因为前两种反应通常来自于需要更多信息的人。在第一种情况中，这个人完全不知道我正在谈论的内容，因此我给他一个快速定义：

　　结对就是两个人一起解决同一个编程问题。

　　正如我在本专栏的第二篇文章“ 揭开极端编程的神秘面纱：“XP 精华”重访，第 2 部分”中所说的，结对的机制看起来如下：

　　结对］通常表示两个开发人员共用一台计算机、一台监视器、一个键盘和一个鼠标（我发现两台监视器、两个键盘和两个鼠标更有趣、更高效，但一套设施也可以干得很好）。您和搭档坐在键盘前。一个人驾驶（“驾驶员”），另一个人为他导航（“导航员”或“伙伴”）。

　　如果驾驶员停滞不前或受到挫折或者失去了思路，导航员和驾驶员可以互换角色。实际上，这种角色互换应该经常发生，有时可能每隔几分钟（甚至更频繁）就互换一次。一旦您习惯了这种做法，并且适应了与您结对的特定人员，您就会进入这种流程，很自然地来回互换角色。

　　当我用这些话向说“噢？”的人描述结对时，他们的反应通常会变成“听起来很有趣”或更可能是“荒唐”。他们可能会问关于结对如何在他们的特定情况中起作用的问题（请参阅本文的论坛，您可以在其中提出这些问题，并且查看我对在您之前提出这些问题的人的回答），他们也可能要说服我这不是一个可行的选择。我稍后再讨论如何应对说“荒唐”的人，首先让我谈谈我听到的最有趣的问题：为什么要结对？

　　结对的好处

　　您为什么要结对？简单的回答是结对可以：

　　◆减少风险

　　◆使团队生产效率更高

　　◆生成更好的代码

　　风险会使大多数团队停滞不前。回想一下您的上一个项目。我敢打赌您会想起您想要做但却不敢冒险去做的一些事，这是因为您太想求稳。别人也一样。减少风险的非常好的方法是确保团队中的每个人都完全熟悉系统的所有部件以及对系统的所有更改。技术讲解和设计文档很有用，但对于大多数快节奏的项目，它们并不能很好且迅速地传播知识。传播知识最有效的方法是让一个知道代码的人与不知道代码的人一起解决问题。

　　结对是经理和团队减少风险并防止因更改而毁掉团队必须运用的最好的工具之一。当团队成员结对时，所有设计决策和代码更改都至少由两个人完成。通过让程序员结对，经理确保了更多人熟悉代码以及它经历的更改。此外，两个人编写的代码总比一个人写的代码好。两个人的智慧确实胜过一个人的，对于影响整个系统的设计决策更是如此。无论一个程序员多么聪明（或自以为多么聪明），第二种意见有助于避免由于无知、自大或只是由于疏忽而产生错误决策。

　　虽然许多程序员保持专心致志可能没有问题，但是让其他人使我们这些凡夫俗子中的另一些人不出闪失当然也是有帮助的。当您尝试解决令人沮丧的问题时，这特别有帮助。当您想要放弃时，旁边有人鼓励您，让您继续前进。团队也不大可能忽略测试或其它重要的细节 — 只有这样才会增加生产力。

　　在我采用 XP 之前的项目中，我的团队随着项目的进展缓慢提速，但随着错误的增多最终又慢下来。但是，在 XP 项目中，我的团队很快达到难以置信的快速，而且一直保持着这个速度。例如，最近团队的速度从第一次迭代的 14 个环节点到第 5 次反复的 60 个环节点以上（请参阅参考资料以获取关于环节点的 XP 概念的更多信息）。其主要原因是我们的代码比我以前所见过的代码更成熟，而且成熟得更快，这就允许我们随着项目的发展而更快地前进。当团队成员结对时，至少有一个人一直在复查代码。这是我听说过的最好的代码复查。

　　XP 中简单性的价值建议我团队中的每个人应该在有效的前提下，对代码和过程采用最简单的方法。当您刚开始时，结对似乎并不简单。这会有点不舒服，需要去习惯它。但 XP 的价值、原理和实践不是鼓励您尽可能地做最简单的事情 — 它们鼓励您在有效的前提下，做最简单的事情。如果有些事情虽简单（比如，让每个人独自编码）但没有效果，那么它并不是行之有效的最简单的事情。有时，在您适应之前，行之有效的最简单的事情难以做到。结对就是一个好例子。以我的经验来看，不结对通常不如结对有效。

　　为什么有些程序员讨厌它

　　我遇到许多程序员，他们都认为结对是荒唐的举动。其中许多人都拒绝尝试它，甚至拒绝以开放的心态来讨论它。我认为他们强烈的反感来自于几个原因：

　　◆他们相信结对会“减缓他们的速度”。

　　◆他们曾尝试过结对，却发现它效率太低和／或压力太大。

　　◆他们需要时间来独自解决问题。

　　◆从更深的角度来看，他们害怕让其他人发现他们并非始终是天才。