[敏捷与极限]关于配对编程的一些看法

我在与同事同学谈到极限编程的配对编程时往往会遭到一系列的反对，产生巨大争议，按他们的理解配对编程根本就是个笑话，他们认为这种开发方式几乎干不成什么事，会将时间消耗在一系列的协作上面，其实我认为这是一种观念束缚，但是他们为什么会反映这么强烈呢？什么是配对编程？配对编程有什么优势呢？

大师Laurie Williams(http://collaboration.csc.ncsu.edu/laurie/)曾将配对编程（Pair Programming）描述为“一种编程风格，它由两个程序员并排在一台计算机上工作，连续协作完成同一个设计、算法、代码或者测试”。由此我们可以知道配对编程不仅仅是编码或实现上的配对，也不是两个伙伴坐在计算机前一个握着鼠标一个敲着键盘的工作，Steve Hayes也曾在他的文章中提到“配对编程不是一个人简单地看着另一个在做什么——在卓有成效的配对工作里，这两个合作伙伴常常工作在不同抽象层次，一个人关注的是为实现眼前目标而编写的代码的细节，而另一个人考虑的是更大的前景和下一步要做的事情，这两个人的角色频繁进行更换。这是一项高强度的、严密的，且常常令人疲劳的活动，但是能够创造出经过深思熟虑的高质量代码。”

我那些同学和同事之所以对配对编程嗤之以鼻，其实都是传统的软件开发习惯造成的，他们无法接受这种新的开发模式，的确难以接受，传统的开发习惯对我们的影响实在是太深刻了，人们一直以为写代码做开发需要一个很安静的思考环境（以致于我们公司开发部都用隔音玻璃与其他部门隔离开了），往往我们在工作的时候都不希望有人来打扰，更何况要采取是两个人结对坐在一台机器前唧唧呱呱的讨论，抢着键入代码拖动控件，呵呵……

如果你现在还是这么理解配对编程（Pair Programming）的话，那就真错了，“当然这些都是一般的想法，但是总有不愿意与其他人肩并肩工作程序员，对他们工作的满意度肯定会受到像配对编程这样的事的影响，一般都是与让两个人在一台机器上工作所花费的时间肯定要比他们各自独立工作然后合并工作成果所需要的时间多一倍的思想有关。”

以下是引用Steve Hayes文章中关于配对编程的描述：

另外一个误解是，配对编程成功与否，应该最终由产出的软件的质量来确定。当两个人合作的时候，至少有三种结果：

软件
对应用程序的共同理解（业务域、设计和实现）
技能的转移
 
这些变化的比例取决于配对的平衡和动态，但是上述所有三者都会在某种程度上表现出来。当一个经验丰富的程序员与一个新手配对的时候，

配对产生的软件可能不会被那个有经验的程序员单独工作产生的软件更多，但是这个新手肯定会学到很多关于这个应用程序的知识以及关于编

程的基本知识。

配对编程的另一个目标是尽可能广泛地传播应用程序设计和实现的知识。

这是通过配对轮换实现的，这样小组配对的每个人都可以通过一段时间和其他所有人进行配对，而且应用程序的特定部分都会由尽可能多的人

来解决。在这种环境里，糟糕的代码不会存在太久，因为它被暴露在很多双眼睛下（这就与开发人员代码开发背后的一个原理相似），而且当

设计周期到来的时候，小组就会从所有人的贡献里受益，而不需要仅仅依赖某个熟悉应用程序特定部分的个人。

配对编程还有其他多种好处：

直接的、连续的代码回顾
与别人工作会增加责任和纪律性。
在有人盯着的时候去偷懒要困难得多！
两个程序员具有相同的缺点和盲点的可能性很小，所以我们会获得一个强大的解决方案。
如果走进死胡同，配对浪费的时间要少得多，因为其中一个人不可避免地会厌烦，从而希望寻求帮助。
 
在定期配对轮换的情况下，上面列表里的最后两项尤其现实。当然，做得看起来像配对编程的方式有很多，但是却无法实现，或者破坏了这些优势。

希望让程序员一天八个小时都配对工作是不现实的——配对的持续交互带来了精确和清晰的结果，但是这一过程也是耗费精力的，而且（一个人）总是会有开发以外的任务要完成。

实践经验告诉我们，配对编程是提高软件质量和减少开发时间的有效方法，但是它并不适用于所有的程序员，它需要一种经过仔细思考的方式实现才能有效。

我的想法：
既然有这么多好处，为什么国内软件行业对于此种方式的排斥如此厉害？
试问：你们公司使用了这种方式吗？想使用吗？
我看怕是少之又少吧？