XP的反省-Pair Programming

常常看到论坛上有人讨论PP（Pair Programming）,但是大多是纸上谈兵，书上云的过多。真正谈感受的少。 我在一家做XP的公司做了4年了，从做service到做product, 总的来说pair programming给我带来的的忧大于喜，缺点大于有点。

 

总的来说PP有它的优点，很多researcher也发表了论文，记得比较清楚的一片就是一个大学里面对一个班的学生分组实验，结果用PP的那组效率比较高。 但这毕竟是research, 给我们的启示是PP在某种特定的情况下的结果:

 

1. Pair的人必须对等 （同班同学）

2. Pair的人必须全力以赴 (同学们，老师在做实验哦，不要走神！)

3. Pair的人必须对要解决的问题有相同（或相近）的认知

 

而上面的3点在现实公司里却大部分情况下不能成立。1就不用说了，2，举个例子，如果有一个人生病，或是惦记的其他的事则会screw up整天的进度。3，和1相关，人的水平不同，不可能像大学那样对一个东西的认知近似。

 

我个人的经验是10%的pair时间是高效的pair，其余的则是浪费时间 。

 

另外从人性的角度来讲，pair on everything则是对人性的xx ，强调沟通没有错误，但是工作毕竟是工作，如果天到晚说比写花的时间更多，则有点本末倒置了。我们公司是100% pair, 任何的task，不管有没有必要，都要pair （条件允许的话）, 老板的原则是绝不让任何一个知识点停留在一个人的脑瓜里：）,一个人躺下了，另一个就能补上。 但是从现实的角度来讲，我们的产品的确出现过超过一个developer走了，结果他们经常working的那个module就会没有人能够维护了，结果需要重写。 所以从knowlege spread的角度来说，公司的benifit和情感留人+document, 比pair来的更实惠。

 

另外pair的确剥夺了developer的个人空间 。 以前的公司， 上网灌水，给朋友 MSN, 的小动作全都不行了：（， 也许有人会说这些的东西在公司应该禁止！ 但是现实一点，我来java eye灌水 ， 跟几个圈内的朋友msn讨论心得，是对工作有正面影响的。 而且msn的圈内朋友对于疑难问题的帮助会很大的。

 

而且还有一点最大的就是pair剥夺了自学的时间 ， 没有pair的时候当有东西不会的时候， 对一个问题的研究会刨根结底，但是pair的时候，如果你的partner会，他大概只会给你概括一下，如果你的partner不会，那就会是一个非常有趣的pairing session, 什么google, yahoo, 大部分情况，结果是 this is a fking task that we should never touch as we dont have corrosponding knowlege... 但是如果一个人能够静下心来把问题的来龙去脉搞清楚，把相应的prerequiste的knowlege搞清楚， 问题在得到解决的同时，自己也会得到提高。说白了当两个新手在pair的时候的确很低效，而且不利于“成长”

 

说了这么多， 一句话

少Pair可以怡神，多pair的确伤身， 不pair也能过日子 。

评论

26 楼 dianthus 2008-06-26  

赞同taowen,我们正确界定目标,不要太注重形式,思想才是核心.

25 楼 sofire 2008-06-26  

男女搭配写程序 都累

24 楼 laiseeme 2008-06-26  

男女搭配 干活不累

23 楼 taowen 2008-06-26  

pair有很多种形式的.不光是简简单单地分配两个人干同一件事情.比如可以一个人写测试一个人写实现.或者一个人写一个测试,然后接着另外一个人来实现,然后再轮换.不同的方式达到的效果是不同的.实际工作中,比较多的情况是高低搭配.一个老手带一个新手.这种时候比较适合老手写测试,新手写实现.然后等新手实现好了之后,老手再指出设计中可以改进的地方,这个时候来演示如何去用重构来改进设计.
这个过程是不是一个很高效的实现功能的过程?当然不是.如果不带pair,那个老手可以以两倍甚至三倍的效率来工作.但是这样的team就没法发展.老手永远没有机会roll off.公司的员工也没有成长.
有的时候,客户指定只买一个人,不买一个pair.后期就发现,那一块东西别人都不知道,出了什么问题都得打电话问以前做的那个人.

22 楼 atusoft 2008-06-25  

Pair on demand

21 楼 jigsaw 2008-06-25  

emarket 写道

这里有一个围城效应。

有机会啦，现在你混哪里？

msn上聊吧

20 楼 daquan198163 2008-06-25  

工作效率提高，难道只对老板有好处么？
你自己不也少加班、有成就、有绩效？

19 楼 microuse 2008-06-25  

robbin 写道

很棒的文章！ 我记得庄表伟评价过PP曾经说过，PP是老板剥削员工最大化的理想方式。

如果效率不能提高 怎么显示出剥削最大化？

18 楼 hover1215 2008-06-25  

robbin 写道

很棒的文章！ 我记得庄表伟评价过PP曾经说过，PP是老板剥削员工最大化的理想方式。

hehe, 还是 理想方式 吗，问题是 ：理想一般都很难实现。

如果哪个老板真想搞这套，我看十有八九会失望。

搂主的老板，我看是：

剥削不成，反被“剥削”。

一男一女，还差不多，男女搭配，干活不累吗！

17 楼 daquan198163 2008-06-25  

emarket 写道

，但如果把pair programming作为公司的一种制度，不分场合的应用例如
1. 高手与低手
2. 两个低手
3. branding work
4. 需要研究的例如 spike
5. 两个人有严重分歧的
6. 有个人生病的，
7. 有严重走神的

1、可以让低手更快成为高手
2、两个低手也互有长短，共同提高，好过一个人闷头做事没进展
3、4没看出有啥特别的，研究型的工作反而更需要有个人多讨论
5、如果不是在结对，其中一个人的错误就不会暴露
6、换个结对的伙伴，其实即便没人生病也应该经常换的
7、PP只会减少这种状况

16 楼 fly_bluewolf 2008-06-25  

robbin 写道

很棒的文章！ 我记得庄表伟评价过PP曾经说过，PP是老板剥削员工最大化的理想方式。

如果老板让人每天8小时都不停的干活的话，估计人早就走光了。
呵呵，robbin不是是这样当老板的吧

15 楼 emarket 2008-06-25  

daquan198163 写道

PP对人性有一定的挑战，需要健康、open的心态和职业素质
楼主不适合

如果个工具对人那么挑剔，必然得不到广泛的使用，试想，如果eclipse说，本软件只适用于身高1.87以上，体重80公斤以下的中年 男性 未婚 的WSN。 是不是很搞笑。

不是说适合不适合，而是要怎么用，我说过10%的pair我人为是高效的。

14 楼 emarket 2008-06-25  

不怕别人拍砖，我并没有100%否定pair programming,曾几何时，跟几位大侠pair的确收益非浅

但是不过根据我的经验 pair programming并不是向某些人所鼓吹的一样能够带来多少好处,相反如果用之不当必然会带来相反的效果

，但如果把pair programming作为公司的一种制度，不分场合的应用例如
1. 高手与低手
2. 两个低手
3. branding work
4. 需要研究的例如 spike
5. 两个人有严重分歧的
6. 有个人生病的，
7. 有严重走神的
... ...

另外有时候两个绝顶高手pair也会有问题,首先从benefit来讲，不大，TDD, refactoring, DI, Pattern已经能够如火纯清，用不着另外一个人看着，多性能处理器似的大脑，已经能够递归到第N层。反而意见的分歧往往会抹杀创造的火花，而提出折中的方案。

我始终主张不要把pair programming理想化，制度化，当你觉得他能给你带来好处的时候，或是没有信心能够独立解决问题的时候，可以邀请另外一个人合作解决。 编程毕竟不是开飞机，独立思考才是创造的源泉。

13 楼 eyejava 2008-06-25  

真正PP的人这么少已经足够说明问题

12 楼 zdonking 2008-06-25  

难得的反对声音。

11 楼 都别装了 2008-06-25  

simbasun 写道

怎么不见gigix出来拍砖? haha

他正在和一彪形大汉PP中，没有空上网

10 楼 simbasun 2008-06-25  

怎么不见gigix出来拍砖? haha

9 楼 jianfeng008cn 2008-06-25  

对，还是要清醒，不要盲目崇拜，搞得自己是老板一样

8 楼 robbin 2008-06-25  

很棒的文章！ 我记得庄表伟评价过PP曾经说过，PP是老板剥削员工最大化的理想方式。

7 楼 fight_bird 2008-06-25  

乌托邦式的开发理念，这样的做法长期下去会拖垮整个公司的开发团队。