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也能过日子 。

老熟人 捧场 鼓掌

要是哪天咱们能pair下就好了 我还从没结对过呢

这里有一个围城效应。

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

pair编程并不是说一天8个小时都在pair programm, 当你领完task要开始编程时，你才pair。不干活的时候，你pair干吗？

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

不干活的时候当然不par, fly_bluewolf 误解我的原意了.  我的意思是不是所有的编程task 都需要 pair

过程改进是干什么用的。

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

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

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