结对编程成为主流，但反响冷淡

　　英文原文：Pair Programming Gets Mainstream Coverage, Lukewarm Response

　　作者 Todd Charron 译者巨泽建

　　华尔街日报开始注意到越来越多的技术公司在实践结对编程，并在题为“计算机程序员在共享中学到深刻教训”的文章中发表了自己的看法。

在技术公司中，结对寻找到了支持者。这些公司包括 非死book 和移动支付创业公司 Square。结对的倡导者对结对的力量赞不绝口，声称结对程序员可以捕获不采用结对时需要花很大代价才能找到的软件错误，而且不太可能花时间上网冲浪。

　　然而，他们很快在实践中发现了问题，就好比约会一样。

现实更像一个永无休止的糟糕的约会。任何困扰同伴的烦恼很快就堆积如山：从不良个人卫生和办公桌整理习惯，到把脚翘到公共桌子上并且大声咀嚼。

Pivotal Labs 是一家软件开发公司，三月份被技术巨人 EMC 并购。Pivotal Labs 的 175 名工程师每天都在结对。一些人不够专一，每天都换同伴，称为“混杂配对”。

　　继续拿约会作类比。

解决与结对同伴的问题，与解决你重要的另一半的问题非常像。

“这与任何关系一样，”Kite 女士说，“如果不谈论这些问题，就无法继续工作。”

　　这篇文章以咨询公司 Drive Current 的故事和他们结对编程的经验作为结尾。

让公司工程师每天三个小时结对，坚持两年之后，Kocol 先生在 9 月份淘汰了这种做法。

“我认为任何人都不会非常想念它。”St. John 先生说。

　　一些开发者加入进来，在评论中发表了他们对结对的看法和实践经验。Anne Bennet说道，

这听起来太可怕了。我们曾有一个经理讨论过结对，万幸他已经离开了。谢天谢地我快退休了。我能理解另一个人来检查代码，但是一起写代码？不适合我。

　　Mike Edwards 有一些正面的结对经历。

我的经验是，对处理那些已经长期忽略并不再维护的遗留代码的程序员来说，结对编程非常有用。有一个目击证人在旁边，这项工作会更好受些。

　　Christopher Wong 认为这取决于各人的个性。

我发现结对编程就像整天困在会议里。我发现这非常累人，让人耗尽精力。但有人因这种安排而充满活力。这看起来是一种个性问题，应该由参与者自行判断。

　　Catherine Jefferson 可以看到它的好处，但认为对她没用。

如果我强迫自己静下心来，思考一下结对编程，我可以想象出，对于有些人和有些类型的编程，结对可能有用。但如果让我在工作中做稍微类似的事，我会在一天甚至更短的时间内筋疲力尽。[颤抖]

　　Thomas Gordon认为这是一种时尚。

哇喔，这个有意思，是种编程时尚。我只是开始担心会混乱，有人要坐在我的膝盖上。我个人很好奇这种共享桌面的方式可以工作。我发现绝大多数程序员真的非常喜欢他们自己的想法，我真的很好奇有人会使用不同于首次出现在他们头脑中的方法解决问题。

　　并非所有人都认同华尔街日报的评价。Roger Neel 是 Mavenlink 的共同创始人和 CTO，他感觉这篇文章对结对的描述并不公平。在他看来，华尔街日报对结对编程理解错了。

我们很早就决定用 Ruby on Rails，开始寻找早期的开发伙伴。我们找到了 Pivotal Labs。在我们项目范围内（Davis 和 Rajan，你们好！），我们讨论了 Pivotal 普遍的敏捷实践，极限编程，测试驱动和结对。当时对我们来说，结对是一种让我们基于他们的最佳实践进行训练的极好的方式。我当时不知道我们会在接下来的三年里在那里工作，并基于敏捷编程雇佣我们自己的团队。

　　Roger 找出了华尔街日报的例证中的毛病。

感谢为我们提供了一个公司的例子。但是，该公司的文化不喜欢结对，该公司的人不喜欢结对。然而，所有其他那些喜欢结对的公司和人呢？

　　他解释了结对的好处，并把结对和瑜伽进行了对比。他解释了两者最初看起来都比较怪异，还解释了瑜伽是如何变成一种主流活动的。

结对的重点是合作，写出更好的代码，教导并让双方相互检查。经过一些练习，合作和交流想法变得更加容易。但并非每个人都能像 Kent Beck 提到的那样，“嘟囔两句就能出代码”。只要你觉得腿还是僵硬的，你就不会停止练习瑜伽；同理，因为你需要一些（或很多）交流，你就不会放弃结对。

　　Roger 认为结对还有其他好处。

结对编程和日常结对轮换可以减少对【很多会议】的需求。如果我们在产品中经常轮换，任何人都会经历多条并行的业务开发轨迹，所以任何一对都可以在日常工作中自己做决定。。

尽管承认结对并不适用于所有人，Roger 还将结对与其他常见实践方法进行了比较。。

一种传统模型是单独构建软件，定期做代码审查，彼此相互作教练。当一个组织非常训练有素时，这种做法很好。但是在现实中，，通常每个开发者都会在每天八小时中需要写 16 个小时的代码。所以他们最后想的事情是，这是别人的问题。另外，没有上下文或长时间投入，我怎么假定我会搞清楚某个问题？针对这个问题，另外一些人已经工作了几天了。短时间的评审经常会导致表面的重构，而非深入的讨论和提高。

通过结合敏捷设计技术和持续的交流与轮换，结对编程是不断达成一致的极好方法。而不是各做各的互不交流，然后事情做到一半又打回重做。

　　你的结对经历是怎样的？如果你是一个结对迷，你怎样把你的想法呈献给那些对这种实践不熟悉的人？

　　注意：你也可以查看我们关于结对编程采用情况的调查结果，或者自己进行投票。