我的{dy}次Pair（Pair Programming的简称，即结对编程。后面都是用Pair代替）是在ThoughtWorks公司面试进行的。那次，他们来自英国的项目经理Andy面试我，和我一起进行Pair。Andy问我以前是否Pair过，我说：“没有，这是我{dy}次Pair”。随即他就告诉我：“It’s very fun.（它非常有趣）。”

就这样，开始了我的{dy}次Pair，也是加入TW最重要的一轮面试。其实，刚开始很不习惯，我那可怜的英语口语，陌生的测试优先开发（TDD Test Driven Development 一种软件开发方式，先写单元测试代码，再写业务代码。我以前也写过很多单元测试，但从没有测试优先）。当我看到需求文档时，大脑几乎是一片空白，不知从何处下手。

但面试总不能就这样放弃吧。我又仔细看了一遍文档，尝试着写了几段业务代码。做在我旁边的Andy摇了摇头，从我手里拿了键盘。他说应该这样做，先写测试代码。于是他一边和我解释业务需求，一边写测试代码。并提醒我，如何去对一个复杂的功能进行分解，并且小步伐的前进。

在Andy的引导下，我慢慢的进入了角色。充分理解业务之后，也就清楚了该如何写业务代码。我从Andy那里要了键盘，又写了几段代码。然后运行单元测试，绿色状态，测试成功。Andy微笑的向我竖起了大拇指。

受到鼓励的我，这是已xx放松进入状态。我们又试着完成了几个功能。这时，我们已经不只觉的渡过了2.5个小时。Pair确实是一件非常有趣的事。

进入ThoughtWorks公司之后，发现在大家不仅Pair编程，还Pair研究技术，Pair撰写文章，Pair翻译，等等。只要是Pair能完成的工作，我们就不一个人完成。甚至在生活中也出现了很多Pair的影子。在我们的西安Office里流传这样一句话：“我们Pair做任何一件事情”。两个人Pair，可以一起一起分享工作乐趣，一起承担工作压力。

这些天的Pair生活，让我深深体会到了Pair的优点。

一、Pair 可以{zd0}化的提高工作效率。 软件开发并不只是程序员堆砌代码的过程，它更多的是一个创新的过程，是一个发现问题、分析问题、解决问题的过程。一个人编程时，往往有了一丝零碎的想法就开始编写代码。写完代码之后，忽然发现这个方案行不通，只好废弃这些代码，重新开始新的想法。当一个人在遇到疑难问题时，很容易走入“死角”。而Pair则不同，一个人有了想法，首先要表达出来，让自己的同伴理解，经过深刻的讨论，一致认可之后才开始编写代码。一个人编写代码，另一个则在旁边思考，会为下一步的工作提出建设性的意见。发现了问题可以及时的指正。大大的提高了代码质量。

一个人{yt}有效工作时间不超过3－4个小时。两个人一起Pair。一个人编写代码，另一个人则从设计的角度思考下一步的工作，有了想法之后，互相讨论，再互换角色。在开发过程中，设计思考和编码实现不停的进行交换，保持了良好的开发节奏。同时可以互相督促，使彼此更加认真的工作。遇到问题和压力时，可以一起面对，互相鼓励。可以一起分享解决问题的成就和乐趣。

二、Pair 是知识传播的{zh0}途径。 很多软件公司都建立有自己的知识库，有的还建立自己的培训部门，甚至高薪聘请一些专家做技术培训。但发现效果并不理想。培训之后，开发人员面临实际的项目，还是一片茫然。而与有经验的同事一起Pair则是在实际项目中学习，具有非常强的针对性。你学到的不仅是一些技术和技巧，更多是他们思考问题方式、解决问题的方法。和各种不同经验的同事一起Pair，你的经验和能力可以得到快速的提高。

在ThoughtWorks公司，如果你要加入一个项目，xx不用担心它使用的技术和涉及的业务。只要你有一定的基础，和有经验的同事一起Pair能让你很快熟悉和掌握它们。

三、Pair 可以打造出{zj0}的合作团队。 团队是有组织有计划的，合理有效地利用各种资源，进行{zj0}的组合。Pair并不是一对固定的伙伴，我们鼓励在团队中经常交换Pair伙伴。这时我们发现，项目不再是一个人的事情，也不是两个人的事情，而是整个团队的事情。

通过Pair，大家可以在最短的时间内完成磨合。Pair很好的促进了团队的沟通交流，经常一起合作Pair的伙伴，彼此了解、熟悉，很多都是工作和生活上的好友。在这样的团队里，大家很乐意互相协助，一起分享知识，分享快乐。

在听过我们一番热情洋溢的阐述之后，某些项目管理者会点头并且认可Pair带来的力量。但，我们也听到了一些拒绝Pair的声音。下面是我们听到的拒绝Pair的最主要的理由，当然也包括了我们的辩解。

一、 Pair 浪费资源。 以前是一个人完成的工作，而现在却是由两个人一起完成。一个人在写程序，而另一个却在旁边观望。为开发人员支付报酬的老板是多么心疼那些白花花的银子。

可是，作为老板的你可曾做过统计过，每天加班工作12小时，满脸疲惫的开发人员到底为你创造了多少的价值？在这漫长的12小时中，能高效工作的时间又能有多少呢？一个开发人员每天编写几百行的代码，可是真正具有实效性的代码又有多少呢？

软件的本质就是很难用一种标准去衡量它的进度和实效性。开发人员能力的高与低、经验的多与少、工作的主动与被动，对软件开发的成本有非常大的影响。前期糟糕的代码，在后期修正，是需要付出几倍甚至更多的代价。在软件的行业里，人月和代码行永远是神话。

在1999年，犹他州立大学（University of Utah）做了一项试验。.两组学生，一组独自工作（一共13人），一组Pair（一共28人，即14对）。他们完成相同的任务（由助教预先设计和开发了测试案例）。

下面的表格（图－1）是完成相同的四个程序，独自工作和Pair工作使测试案例成功通过的百分比。

（图－1）

下面的柱状图（图－2）则是完成相同的程序，两组所花费的时间比。虽然Pair的学生在刚开始的阶段比独自工作的学生花在同样任务的时间较多，但很快Pair的学生的时间开始大幅度的下降。而独立工作的学生需要花费比Pairs更多的时间来达到接近的代码质量。

（图－2）

而且，在具体项目中。Pair会带来比上面结果更高的价值。一、在实际开发中，如果错误越多，就要花费越多的时间去修复它。在我们的试验中，没有统计修复错误所花费的时间。二、从图－1可以看出，Pair在产生高质量代码时，也即意味着对需求的准确理解。个人团队对需求理解偏差比较大，后期也要花费更大的代价来纠正。三、从图－2可以看到，Pair的团队开发能力提高很快，这是潜在的价值。

在比较试验之后的问卷调查之后发现：

• Pair能用较少的时间生产更高质量的代码。
• Pair的学生们认为自己比一个人的时候更勤奋和更聪明的工作，因为不想让自己的partner失望。
• Pair的学生认为自己比一个人的时候更专著,紧凑和由纪律的工作，而且是持续的。而独立工作的学生也可以专著和紧凑的工作，但往往不持续。
• 在紧张时间安排和繁重的工作压力下，独自工作的学生很容易蜕变为没有纪律的程序员。

同时，在ThoughtWorks这样的咨询公司，每个开发者都是能够独挡一面。ThoughtWorks的开发者，在一般的软件公司都是类似项目经理或架构师的角色。你可以想象公司肯定要为他们提供不翡的待遇。可是，他们却Pair做任何一件事情，也从不认为自己是在浪费资源。相反，ThoughtWorks从实践中得出：Pair能够充分的利用每个开发者，让他们发挥{zd0}的价值。

二、人手不够。 也许，在你的公司，昨天又有一个老员工递交了辞职申请。老板看着一张张新的面孔，很无奈的摇了摇头。招聘员工并不困难。但如何让新员工快速进入角色，掌握公司的技术和业务呢？

人员的流动一直是让很多软件公司非常困扰的问题。特别是老员工的离去，也就意味着公司多年的技术和业务积累的流失。

而在Pair工作的团队中，几乎不用担心这个问题。Pair可以快速的进行知识传递，通过Pair和Pair伙伴的交换，知识不再是掌握在一个人的手中，而是整个团队一起共享。

在ThoughtWorks内部，工作的调整和变换是非常频繁的。但很少会对项目造成影响。相反，这样的变换却加快了知识的传递。

三、开发者不能很好的合作，Pair 对开发者要求太高。 真的要求很高吗？看看求职简历，不是每个开发者都口口声称自己具有很好的团队合作精神吗？如果你不能很好的和别人Pair，团队精神又从何谈起呢？

那任何两个人都可以搭配进行Pair吗？

不，Pair对开发者是有要求的。它要求开发者乐意和别人沟通、合作，要求开发者能够彼此尊重，愿意和别人分享自己的知识。这不正是我们一直倡导的团队合作精神嘛！

Pair的搭配是一个有趣的问题。有人说，{zh0}的搭配就是两个人能力相当。其实不然，Pair应该是一种多样的变换组合。在Pair的团队中，经验丰富的开发者有责任带领新人，传知授道xx，同时可以享受传道的乐趣。新人，更应主动找有经验的伙伴Pair，快速学习提高自己。Pair的核心就是沟通，只要两个人能很好的进行沟通，那么他们就可以很好的搭配。

关于Pair的实施，其实并不困难。我们需要的只是经验，当然经验也只会来源于实践。

{zh1}，我要说的是：我在ThoughtWorks中国，有幸多次和传说中的美女天才程序员一起Pair，其中的感觉也就不用多说了，呵呵。

参考资料：

http://www.pairprogramming.com/ 这是一个专门介绍和研究Pair的一个网站