我为什么不喜欢结对编程

结对编程就像一个挥之不去的幽灵。它的拥护者宣称它是最佳的编码方式，而我们其他人却依然置之不理。我只尝试过几次。基于这几次经历以及我读到的资料，我并不想再尝试了。我非常喜欢协作、指导和代码审查，但这种持续结对编程的方式对我来说实在没什么吸引力。让我试着找出原因。

如果你经常进行结对编程，请分享一下你的经验与我的观点有何不同。我想看看我遗漏了什么或者理解有误。

经验的二分法

结对编程的原则之一是，两位成员必须对编程过程做出同等贡献。如果做不到这一点，最终的结果就更像是指导关系。我喜欢指导，但这和结对编程并不相同。

工作中出现经验上的差距是正常的。我指的不仅仅是“基本技能”，而是指从对代码的熟悉程度、对业务的理解到相关领域的背景等方方面面。任何工作中，总会有人比其他人更适合。

双方差距如此之大，我看不出结对学习如何才能避免变成指导关系。虽然知识共享是好事，但我不确定如何才能避免主导一方的生产力大幅下降。

如果我理解正确，这种差距正是结对编程旨在解决的问题之一。它的目标是缩小这种差距。我能理解新项目成员在第一个月内可能会遇到这种情况，但我并不认为整体经验差距会缩小——这岂不是意味着资深成员的经验停滞不前吗？

连续的想法

共同的经历要求参与者以类似的线性方式思考。为了能够接受反馈，我必须专注于正在编写的代码。如果我有什么想法，我必须大声说出来，让我的伙伴了解我的想法。我的外在行为必须与我的内在过程清晰地对应起来。

问题在于我的工作方式并非如此。我写的代码只是我脑海中完整构想的片段。我会反复查阅各种源文件，将构想拼凑起来。有时，代码看起来可能会很混乱。如果你打断我的思路，直接询问这些片段，会打乱我的思路，我可能需要一段时间才能整理好思路并解释清楚。

当然，我可以解释我写的代码；能够做到这一点很重要。问题在于在线分享这些知识的要求。结对编程迫使我把思考过程串联起来，这造成了很大的阻碍。

持续分享也会给大脑带来负担。每当问题过于复杂，让我无法同时分析和表达时，进展就会受到极大阻碍。我承认这种情况并非我们大多数工作都会遇到，但这类问题确实会发生。

这不是结对“编码”吗？

编程远不止编写代码，请参阅我的文章《我为成为一名程序员而自豪》。然而，在我所见过的所有描述中，结对“编程”实际上都只是编写代码。或许应该称之为结对“编码”。我并不关心术语本身；我更想知道它在整体框架下的意义。

我不认为编码是编程过程中一个独立的阶段。编写代码、分析需求、与其他团队成员沟通、在另一个分支上编写修复程序、进行研究、在在线论坛发帖、享用一份思考的三明治，最终回到最初的代码，这三者之间是一个持续的流程。

我对任何允许个人将大段不受干扰的时间投入纯编码的流程都抱有怀疑。总感觉哪里不对劲。难道需求真的如此清晰，无需更多反馈？难道这个人的背景真的如此契合，以至于无需任何调研？结对编程本应避免这种孤立感，但似乎同时又需要这种孤立感。

工具和远程工作

对于一个已经优化好自己工作环境的程序员来说，使用别人的工作环境可能会让人感到不适应。许多细微的改变，例如颜色选择、键盘位置、屏幕高度、字体选择等等，都会影响我的工作效率。虽然最终我能够适应，但每次切换环境都会导致效率下降。每当我需要在自己的笔记本电脑上工作、进行代码直播或连接到远程系统时，都会遇到这种情况。

远程办公也是个问题。每周一天不在办公室办公，或者长期远程办公，确实有很多好处。但我看不出这种设想中的结对编程方式在这种情况下如何运作。我见过的工具不足以支持它。双方都会身处陌生的环境，生产力必然会下降。

为什么不合作呢？

我对结对编程最大的批评或许在于，它过于强调两人独立工作，而不是像团队成员一样协作。为什么不能同时编写代码？为什么不能一人编写测试，另一人编写功能代码？为什么不能一人进行研究，另一人查找缺陷？

我曾有过与两位专注于某个问题但各自从不同角度着手的合作经验，效果很好。他们不断分享想法、审查代码并寻求帮助。团队关系灵活，无需任何人放弃自己的工具。经验差距也无关紧要——即使他们的工作速度不同也没关系，经验较少的成员可以根据需要获得导师的指导。为什么不能采用结对编程呢？