Agile 101: Pair Programming & Simple Design
raimundox
要 了解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，几乎不会逛论坛。你不好意思呀，毕竟不是你一个人的机器，毕竟是两个人的时间，毕竟你也不愿意给 同事一种懒散的印象吧？收回的这么浪费的时间，至少顶得过另外一个人的工作时间了吧？
盖浇饭
质，或配以其它管理手段。否则，如果出现pair programming过程中一个编程、一个打瞌睡的情况，该如何呢？
On 3月27日, 下午2时54分, raimundox <x...@bjug.org> wrote:
> 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
Jeff Xiong
如果一个人在跟别人pair的时候都可以打瞌睡
还有任何别的办法可以让他不打瞌睡吗
--
Jeff Xiong
Software Journeyman
盖浇饭
工都是朝气蓬勃的状态。这样的人是不适合采用pair programming的。可能传统的绩效方法更好管理。
Jeff Xiong
programming可能是发现问题的最佳途径。至于发现之后怎么处理，基本上是一个企业管理的问题，而不是敏捷开发的。
On 3/27/07, 盖浇饭 <song...@gmail.com> wrote:
> 打瞌睡实际上是表面现象，说明他对待工作的态度不一定很积极。这样的人采用pair programming是体验不出任何优点的。但我不能保证每个员
> 工都是朝气蓬勃的状态。这样的人是不适合采用pair programming的。可能传统的绩效方法更好管理。
>
>
> >
>
盖浇饭
On 3月27日, 下午4时52分, "Jeff Xiong" <gigix1...@gmail.com> wrote:
> 这个问题分为两部分：发现"工作态度不积极"之后怎么处理，以及如何发现这件事。pair
> programming可能是发现问题的最佳途径。至于发现之后怎么处理，基本上是一个企业管理的问题，而不是敏捷开发的。
>