结对编程的误解

关于结对编程的一些常见误解。

如果你正在进行敏捷流程，你就必须进行结对编程。

这完全是错误的。“敏捷”是一个非常广泛的术语，只用价值观和原则来定义，最著名的是敏捷软件开发宣言。宣言中没有提到结对编程，大多数敏捷方法也没有将其纳入其方法。

由于结对编程是XP的一种实践，它对敏捷社区产生了很大影响。因此，它经常被提及为敏捷实践——这意味着在敏捷项目中的人们经常使用的一种实践。但这只是一个观察结果，而不是处方。

极限编程迫使你进行结对编程

这是一个更微妙的问题。结对编程是XP的实践之一，从一开始就是如此。这里微妙之处在于，一个声称正在进行XP的团队是否必须遵守XP的实践。这实际上比乍看起来要棘手得多。XP与任何敏捷方法一样，都期望团队选择自己的流程。在《极限编程释义》中，肯特说实践是“你每天都会看到XP团队在做的事情”。我认为结对编程对XP团队来说很常见。我不会说一个没有进行结对编程的团队就不能称自己为XP团队。我还应该指出，对于我认识的大多数XP实践者来说，一个团队是否是XP团队并不重要；真正的问题是团队是否有效。

我离强迫结对编程最近的一次是说，如果你想学习如何进行XP，你应该尝试结对编程，看看它是否适合你。

我不需要尝试结对编程，因为我知道我不会喜欢它。

这句话的问题在于，许多人对结对编程感到惊讶。他们尝试了一下，以为自己会讨厌它，却发现自己真的很喜欢它。

许多人尝试结对编程的方式很糟糕，这进一步加剧了这个问题——这会给人一种错误的印象。在角落的隔间里被动地盯着某人的肩膀看几个小时，这不是结对编程。确保你身边有真正懂得如何指导你的人，这样你才能确定你是在评估真正的结对编程。

结对编程将开发人员的生产力降低了一半。

我对这个问题的轻率回答是：“如果编程中最难的部分是打字，那确实如此”。

结对编程的倡导者之所以成为倡导者，是因为他们相信一对开发人员实际上比两个独立的开发人员更有效率。这是由于结对编程引入的持续讨论和审查。你会想出更好的设计，犯更少的错误，让更多人熟悉代码。所有这些都抵消了打字人数减少的影响。

当然，由于我们无法衡量生产力，我们无法确定。我的观点是，你应该尝试一下，团队应该反思一下，他们是否认为在进行结对编程的情况下比不进行结对编程的情况下更有效率。与任何新的实践一样，确保你留出足够的时间，这样你就有机会跨越改进鸿沟。

只有在编写复杂代码时才值得进行结对编程，编写重复代码没有优势。

我认为这一点是有道理的——结对编程是为了改进设计和减少错误。编写简单易写的重复代码，结对编程几乎没有发挥作用的机会。

除了这一点：编写无聊的重复代码是一种代码异味。如果我正在编写无聊的重复代码，这通常意味着我错过了一个重要的抽象，这个抽象将大大减少要编写的重复代码量。结对编程将帮助你找到这个抽象。