六种不同的结对编程模式对比

结对编程| 2017-10-14

作者：Erik Dietrich
译者：月满西楼
原题：Compare 6 Different Pair Programming Styles

专业编程领域总是产生一些相当激烈的争论。例如关于是否以及怎样对代码作注释。我们很难平息这些争论，因为科学地论证专业编程是有难度的。我们不可能真的要求大公司用一个对照组与一个实验组两次构建同一个软件。因此很多时候我们的依据是传闻或个人意见，极缺经验数据。因此，相比是否该选择结对编程，今天我更想谈谈结对编程的模式。

我先前曾从业务角度谈论过结对编程的好处，现在我以同样的方式来介绍今天这篇文章。你能从中获益，但你必须评估它对你是否有意义。要想做好评估，你就应该了解不同的结对编程模式以及它们都是如何运作的。

没错，结对编程并非只是把两个人扔一起、让他们疯狂撒欢。多年以来，从业者开发了一些应用于不同情况的技术，通过实践与实验，他们对这些技术作了提高与完善。

一、熟练程度不同结对编程模式的影响

看实际方案之前，让我们先绕个小弯看看不同开发人员的技术水平。尽管我们看似特别倾向于细致地区分不同技术水平，但我觉得实际只存在两种开发人员技术水平：初学者和专家。我懂，我懂，你们一定觉得这种分法太草率了，但这样确实可以把复杂性降到最低，且能很好地解释不同结对模式。根据我们这两种技术水平，能得出以下三种结对组合：

• 专家-专家

• 专家-初学者

• 初学者-初学者

请注意，我这里谈及的专业技术，是背景的一部分，而不仅仅是一般的行业经验。技术的积累、对代码库的熟悉程度、甚至还有专业领域知识在这都很重要。我有两个计算机科学学位，对几种面向对象的编程语言也有数年经验，但如果我哪天加入你的Go语言团队，你可以妥妥地把我放在初学者阵营直到我找到自己的定位。

每种结对模式有它的优缺点，然而有时候命运可能迫使你根据哪个人有空来做出选择，到时候对不同结对模式的了解会助你更有效率。另外，值得一提的是，初学者-初学者的组合可为二者提供很多的学习机会，但有风险。因此，这种组合的适用性更多地取决于你对风险而非结对模式本身的倾向。

二、非结构化结对模式

设想一下结对编程诞生时的情况，李四走到张三的格子间办公室，说：“嗨，我们一起用FORTRAN语言工作吧。”好吧，这么个小故事也许不足为信，不过想象一下它会怎么发展吧。李四和张三习惯把编程作为独自的工作，某天却决定把他们的智慧结合在一起。他们不一定知道任何编程协作的技巧，所以他们临时结伙，试着互相帮助。

这是我要列举的第一种协作示例。如果觉得很荒唐，那你要错过这堂课了。知道一些技巧可以尝试当然很有帮助，但不要麻痹了你的分析能力。如果你想起步，试错（测试与出错）会有很大帮助。就像下面的结对技巧通过试错而不断进步，你自己也需要这样。

但也要知道结对的组成中也存在着限制。它需要两个够格的头脑和单单一台计算机，所以当你在编程而你的伙伴在检查她的邮件是不行的。你可以视情况用些不同的沟通技巧，如“键盘用一个还是两个？”、“谁来打代码？在什么时候？”

三、驾驶员-领航员模式

就已建立的模式而言，我们先来看一下驾驶员-领航员模式。理论上这可构成最成熟的模式。

它的名字源于两个人可能作汽车旅行穿越未知区域的场景，驾驶员的注意力集中在机械方面，包括操控油门和刹车，调转车轮还有提防障碍与其他车辆。与此同时，领航员则考虑更宏观的问题。还要开多久才能下高速？手机是否能及时收到任何突发交通堵塞的提示？

把这对关系的比喻应用于编程，那么驾驶员就负责写代码，浏览文件，还有基础实现方法。领航员则着眼更长远的考虑并且检查错误。这方法适合这种架构吗？我们有没有可能另辟蹊径重写一个实现方法？我们是否困在死胡同里了？

如果二者都是可互换角色的专家，那么驾驶员-领航员模式会很理想，对于专家与新手的组合来说也不错。这个模式在专家做领航员时最容易起效，因为让菜鸟来当领航员，他可能只会被动地干坐着而让专家分饰两角。

四、后座领航员模式

接下来要讲的结对编程模式是后座领航员模式。这方案看起来像是驾驶员-领航员模式，但领航员接管了更多具体策略的工作（让人联想到后座驾驶员）。

和驾驶员-领航员模式一样，驾驶员在键盘前坐着，执行诸如写代码的工作。但不像驾驶员-领航员模式，后座领航员下达的是更细致的指示。这意味着她可能告诉驾驶员什么时候创建一个方法或打开一个新的文件。她还会告诉他应该如何为一个测试或变量命名。

这种模式在以初学者为驾驶员的初学者-专家组合中发挥得最好。初学者在按照专家指示做事的过程中得到学习。

五、向导模式

另一种非常适合专家-初学者组合的模式是向导模式。同样，驾驶的比喻依然适用。

设想去某地度假并在当地旅行。驾驶员登上客车或巴士，开始驾驶，然后告诉你他正在做的每件事情和你所看到的每样事物。你的地位就很被动。

向导模式编程模式也是这样。驾驶员做战略与策略上的思考，同时写代码。当她这么做时，她告诉“游客”她正在做什么。游客很少介入。

这在专家驾驶员与菜鸟游客组合上很有效，尤其是菜鸟一无所知的情况下。但如果角色互换，它其实也同样有效。初学者可以在专家的观察下探索解决问题，专家则提供反馈与纠正，如此反复。

六、乒乓结对模式

要认真完成结对编程模式的学习，你还得了解乒乓结对模式。这种模式有个不同于其他模式的有趣因素。

为了便于理解，把结对编程看成一项极限编程运动，这些人深爱着结对编程和其他具体应用，如单元测试。因此当你遇到一个极限编程者，你可以稳妥地认定她喜欢结对也喜欢实践测试驱动开发（TDD）。

这个步调很简单，前一个人写一个失败测试而后一个人设法通过。接着后一个人写失败测试让前一个人设法通过。如此来回往复，有点像乒乓球。

这种模式在两个专家的组合时进行得格外完美，初学者-专家组合也进行得相当顺利。另外很有趣的是，它可能在初学者-初学者组合下效果最佳，前提是以锻炼初学者为目的。乒乓结对模式下，两人角色转换得非常频繁，使得他们总能一起思考，因此所有的组合都能进行顺利（尽管会带来一些人际关系问题）。

七、分布式模式

我将以一种“非正式”的结对模式收尾。不过这种配对模式极有可能掌握着未来日益全球化的分布式世界的关键，我说的正是分布式结对模式。

极限编程始于90年代，当时，远程工作需要Citrix系统与拨号调制解调器。换言之，你在任何地方都做不了协作编程工作，只能由个人完成。但20年后，托管的硬性要求随着技术发展而弱化了。你可以用Screen Hero之类的软件无缝衔接。显然，就个人而言，协作仍然更有效，但技术已经缩小了很大的差距。另外，人们随时随地协作产生的长远收益是不可否认的。

相信在未来，结对编程模式还需要加入经得起考验的技术。不过我认为分布式模式会变得更加多元化。前面几种模式随着时间推移均进行了技术的更新与完善。我认为不到20年，我们将看到一些颇明智且复杂巧妙的结对编程模式。

关于作者

Erik是DaedTech的创始人。他是一名程序员、架构师、IT管理顾问、博主和技术专家。

关于EAWorld

微服务，DevOps，元数据，企业架构原创技术分享，EAii（Enterprise Architecture Innovation Institute）企业架构创新研究院旗下官方微信公众号。