当结对编程不再有效时

从概念上讲，结对编程与字面意思基本一致。两名工程师在同一个代码库上工作，完成同一个任务。传统上，这最多只使用一台机器。如今，情况可能会变得更加微妙，尤其是远程工作如此流行。不过，无论设置如何，以下情况都是正确的：

一项任务的开发时间最多可增加 200%。你可能会认为不可能增加 100% 以上，毕竟只是多了一个工程师在做同样的任务。然而，这种想法太天真了。实际上，结对编程往往要花费两倍以上的时间，因为工程师们经常会讨论各种方法，甚至会在事后再讨论。通常情况下，技能也会不平衡。例如，一名资深工程师和一名初级工程师做同一项任务。为了配合初级工程师，资深工程师会故意放慢速度来跟上初级工程师的节奏。这是正常且必要的，因为结对编程通常也期望有教与学。这也适用于两名水平相近的工程师在同一项任务上工作，但其中一名是代码库新手的情况。

生成的代码可能错误更少。从技术上讲，这应该是真的，因为四只眼睛比两只眼睛看得更多，对吧？然而，在现实中，事情可能会发生截然不同的结果。要使这一假定的好处成为现实，必须有两名非常强大的工程师参与结对编程。如果只有两名初级工程师，同样的设置不会产生任何相同的好处。

驱动者和观察者。传统上，这些角色在会话中经常变化。有些人每 20 分钟转换一次角色，有些人每小时转换一次。还有一些情况是，大部分情况下只有一个人在驱动，另一个人在观察。原因可能各不相同，而且往往是基于上下文的。然而，无论上下文如何，这意味着两个人都积极参与，专注于解决这个问题。上下文切换——一项很棒的技能——是无法发生的，因为它会降低体验。许多工程师在结对编程时倾向于关闭或静音所有其他沟通渠道。

此列表虽然可能不是最详尽的，但它涉及关键方面，我认为值得仔细研究，因为我看到更多的工程团队争论结对编程而没有展示切实的好处，而务实的团队则不认为结对编程是一种实践，而是一种偶尔使用的工具，有时可用于实现更高的速度或更好的团队生产力。

作为一般做法

我们都听过这样一句话：“当你手里只有一把锤子时，一切都是钉子”。这句话也适用于结对编程。当结对编程被用作一种普遍做法时，团队几乎在任何事情上都依赖它。它突然成为——而且几乎是唯一的——新成员入职、新团队入职的工具，文档、指导、知识共享的替代品，以及现状和工程文化的全面传播。

当你参加那些自以为已经解决了所有问题的人举办的技术聚会和会议时，你会经常注意到一种非常相似的氛围，就像那些敲门向你推销另一种宗教、在小册子中提供“救赎”的人一样。作为过去真正加入过宗教派别的人，我亲身体验过当人们试图传教时会变得多么狭隘。同样的情况也适用于那些依靠结对编程来解决大部分问题的公司和团队。他们会试图改变周围的每个人。不用说，有些人会上当，有些人会彻底拒绝，不幸的是，两者都是错误的，因为结对编程有其时间和地点，这就引出了我的下一个观点。

作为工具

现代软件开发的好消息是，我们现在拥有大量工具，可以实现更高的速度、更好的开发人员体验、跨职能、敏捷的团队和高质量的产出。如果在正确的情况下正确使用，结对编程就是其中之一。

根据个人和二手经验，我认为在以下场景中结对编程非常有价值：

作为新成员加入团队的入职培训课程。在这种情况下，新成员首先会关注团队中经验丰富的成员所阐述的各种概念。在解释了主要概念之后，新成员将接管编码并尝试复制之前所做的事情。当然，这并不意味着不需要以后可以参考的可靠文档。这只是一项练习，以确保代码库的新手能够掌握基础知识。

调试会话。我们都知道这些是什么，以及它们可能发生的所有场景。我认为结对编程在这种情况下非常有效，因为它可以实现即时反馈循环。两名工程师试图追踪同一个错误并找到可行的解决方案。这不是传统的场景，因此驾驶员和观察员的角色可以在两者之间快速交替。

解决复杂挑战。编程的复杂性是一个非常相对的事情。有些人倾向于过度复杂化他们的方法，而另一些人则过度简化复杂的挑战。无论哪种方式，有时你会发现你需要另一个人来观察你正在做的事情，并通过简单地指出你忽略的复杂性或降低复杂性来帮助你摆脱困境。后者是我多次做过的事情。工程师们会陷入困境，并通过一个简短的结对编程会议意识到解决方案实际上很简单，引导他们找到解决方案是一个很好的学习经验，这让我想到了我的下一个也是最后一个案例。

教学或学习。在软件开发中，你不可能知道所有的事情。当心那些声称自己知道所有答案的程序员，他们已经没有什么可学的了。结对编程可以很好地教会别人一种新技巧、一种新方法。这在医学科学中非常常见。例如，外科医生从已经掌握新技术的同行那里学习新技术。也许有人正在努力掌握 JavaScript 承诺或事件循环。这是一个使用结对编程作为教学工具的好机会。

也许还有更多场景可以使用结对编程。这里的底线是，它不是工程文化支柱，而是需要的人可以使用的工具。

结对编程不适合什么

除此之外，我还想强调结对编程无法产生效果的情况，而且有充分的理由。就像我说的，它是一种工具，而不是一种标准做法，即使作为一种工具，如果在错误的环境中使用，它也会弊大于利。

到目前为止，软件工程团队面临的最常见问题是缺乏文档。要么没有文档，要么文档已经过时。不过，这对团队的影响仍然非常明显。一些人（甚至很多人）认为结对编程是低于标准或不存在的文档的绝佳替代品。不编写文档和不维护文档既不体贴，又目光短浅，总体来说是一种马虎的开发实践。在现代工程组织中，依靠口口相传的方式向工程师或团队传播知识是完全不可接受的。

结对编程也不是拐杖。你会发现许多初级工程师会过度依赖结对编程，以至于他们完全失去了交付代码或制定工程问题解决方案的能力。这是一种非常危险的状态，对一个人的职业生涯非常不利。在软件开发中达到高级水平的唯一方法是获得独立性。这意味着能够主动承担任务，理解挑战并在无人指导的情况下提供解决方案。

最后，它也不是用来闲逛的。听起来很荒谬？再想想。当团队中的两个人一起编写相同的代码时，除了一起尝试解决挑战之外，他们不可避免地会闲聊一些随机的事情。这很正常，毕竟我们是社会动物，但是当花在闲聊上的时间与解决问题上的时间一样长时，你就有了一个新问题——浪费资源。现在，你不仅要将开发成本翻倍，而且还要将其翻三倍甚至四倍。结对编程会议需要相当多的纪律，重点应该放在解决问题上。交换寒暄当然没问题，但除此之外，你还冒着浪费实际金钱的风险。还有（应该有）其他论坛可以建立联系并发展友谊。

反驳论点

我觉得，与其做总结，不如做个提醒。结对编程并不是什么新鲜事。事实上，考虑到过去几十年软件开发的巨大变化，结对编程这个概念已经非常古老了。重要的是要记住，它在 90 年代开始流行。在2000 年（也就是 24 年前）进行的一项在线调查中，大约 95% 的受访者是结对编程的粉丝。然而，有一个很大的问题。所有受访者都是自选结对程序员。这有点像问烟草制造商，制造香烟是否还应该是一项生意。

在敏捷开发流行之前、在 Web 2.0 出现之前、在 AI 出现之前、在超级智能 IDE 出现之前、在我们如今开发软件所依赖的一切出现之前，结对编程就已经很流行了。科技公司存在于一个完全不同的领域。竞争看起来不同，开发速度与今天的标准相差甚远——想想持续集成和交付。

最后，在推动结对编程作为解决所有编码问题的解决方案时，似乎没有人考虑到工程师的个性。就像许多高级软件工程师在面试时会断然拒绝现场编码一样，许多人会因为同样的原因拒绝结对编程——这不是他们的工作方式。这不适合他们的个性。例如，作为一名高级工程师，我要同时处理很多事情。我每天都要切换几十次上下文。

我的工作职责之一就是除了编写我必须交付的代码之外，还要为其他人服务。想象一下一直参加结对编程会议。我必须将注意力集中在一名工程师身上，而忽略其他一切和所有人。

有些工程师还喜欢在编码时听音乐或播客。他们喜欢全神贯注。他们不是不善交际，这只是他们获得精通和成功的方式。其他人则喜欢在工作时多次短暂休息。例如，除了午休，我实际上从未休息过。然而，在一天的其余时间里，我会查看我的信息、电子邮件，花 4 分钟时间在 YouTube 上观看我最喜欢的艺术家的最新音乐视频。在结对编程中这样做是不尊重和不明智的。