Agile 101: Pair Programming & Simple Design

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，几乎不会逛论坛。你不好意思呀，毕竟不是你一个人的机器，毕竟是两个人的时间，毕竟你也不愿意给同事一种懒散的印象吧？收回的这么浪费的时间，至少顶得过另外一个人的工作时间了吧？

可见raimundox今天没有pair programming.

一个前提条件是：要频繁switch pair，至少要每天switch一次，否则就达不到simple design的目的。

可以灵活的实现pp，遇到困难进行讨论，对设计进行研讨，编码的时候相互指导，知识共享，，，，PP确实给我们带来了好的效率。

有点意思。
不过从来没有感受过。
不过simple design的标准不会很清晰的。
有的时候，一致性也是简单的一种体现，那么，此时相对复杂但处处一致的设计也成为一种简单了。

以前在哪本书上看过说pair要经常换，而且键盘鼠标也要轮流控制，上次还有人说一个控制鼠标一个控制键盘

这句话很有感触！

轮流控制和分别控制不一样啊。。。

这个我非常同意，但是simple design往往也是不容易实现的
我最不喜欢看到的是传说中的牛人搞了一套极“牛”的构架，等牛人一离职
这套构架就不易改动了，也差不多就腐烂了，废弃了，
pair的另外好处就是保证了系统不是掌握在一两个人手里
就算团队里面重要成员突然离职，对整个项目的影响也不大
其实对公司也是个风险控制的好方法

就是说有两种，一个是轮流控制，一个是分别控制，但是我觉得轮流控制比较好，分别控制难度太高了，需要极大的默契，否则速度反而慢了