pair programing是所有XP实践中争议最大的一个，但窃以为确实XP实施的关键关键实践之一，甚至于，我认为很多XP实施的失败都是由于没有采用pair programming而造成的。
要了解pair为什么重要，就要了解pair的目的在何。当然了，大多数人都知道pair的重点在于知识传递，知识共享，持续走查，降低代码缺陷等等等等。这些都是pair的优点，不过最重要的一点却常常被忽略——pair programing的最直接而又最根本的目的之一在于simple design。
上图是著名的Ron Jefferies Model，可以看到XP最佳实践被划分成了一个一个的圆圈，而pair, TDD, refactor和simple design位于中心。这并不是说这四个实践就是xp的核心。jefferies model每一圈代表了xp实践过程中的不同关注点，最中心的是dev视角，其次是team视角，最外层是交付／管理视角。每圈上的最佳时间多少都有些紧耦合，放开其他的不讲，我们专门说说dev圈，pair programing, tdd, refactor和simple design。
这四个实践里只有simple design最虚也最重要。有一个问题已经被问过无数次了，“到底多simple的design才叫simple”。我对此也有一个近乎刻板的回答：team里所有人员都能够理解的design就是simple的。一旦立了标准，这四个实践的主从关系就一下子清晰起来——simple design是这四个实践的核心，其他三个实践都是它服务的。
首先做出一个设计，最简单的判断标准就是是否可测，一个不可测的设计基本上可以认为无法实现，于是TDD即是simple design的质量保证又是simple design的直觉验证。
refactor是为了得到好的代码，那么什么是好的代码？simple design!!!这里有人不同意了，有人说只是要易于修改和扩展，可是扩展和修改也要别人看得懂才行啊...simple design是起码的要求嘛。实际上，XP中的refactor就是朝着simple design的方向重构过去的，也就是朝着所有人都能理解的代码refactor过去的。插一句题外话，为啥说好的架构的不是设计出来的呢？因为好的架构至少应该是simple design的，而simple的概念有和人员相关...所以当你极尽能事show off你的pattern知识之后，得到复杂设计根本就不可能是好的架构。时刻紧记，架构是妥协啊...
最后，pair programming是simple design的实际检验！！！因为即便是最复杂的设计，只要是你自己想出来的，你都觉得它简单无比，里面充满了直白且显而易见的理由。可惜不幸的是，我们要的简单，是对team里所有人的简单。如果你的pair不能理解你的设计，那么说明你的设计复杂了;如果你们两个人懂，但是swith pair的时候，换过来的人不懂，说明你的设计复杂了。pair programming(以及他那容易让人忽略的子实践switching pair)就是检验simple design的过程。pair programing + refactor就是时刻保证simple design防止过渡设计反攻倒算的过程。pair programming + refactor + tdd就是团结在以Deming同学built quality in的质量大旗下，坚定地与过渡设计做斗争的过程。据我观察，至没有使用pair programming的团队中，少一半simple design成了口号，而这一半中，至少又有一半最终放弃了xp放弃了敏捷（俺以前带过的团队就有这样的...默哀一下）。深刻的教训啊，我们来高呼一下："pair programming是检验simple design的唯一标准！"。
最后说一下pair programming经济学，过多的假设我就不讲了。单说一点，有哪一位上班的8小时从来不上msn/yahoo/qq等im?有哪一位上班从来不上论坛/不回贴/不发邮件?以我pair的经验来看，pair programming的过程中，两个人几乎不会用im，几乎不会逛论坛。你不好意思呀，毕竟不是你一个人的机器，毕竟是两个人的时间，毕竟你也不愿意给同事一种懒散的印象吧？收回的这么浪费的时间，至少顶得过另外一个人的工作时间了吧？