关于pair coding

极限编程中，有一项实践是pair programming， 是说两个dev在一起programming，用一台机器，两个显示器，两套键盘鼠标。在agile中，人们对TDD 和 CI的质疑比较少，基本上还是赞同的。
  但是对于pair programming， 却存在很多的质疑，到底pair programming是不是一个好的practice？pair programming到底有什么优势？有什么弊端？什么时候pair是适当的，什么时候又是不合适pair的。
  agile推崇pair，据我所知，主要是因为pair可以share knowledge，可以帮助一个新进入项目的人或者一个缺乏某一方面知识的人很快的进入状态， 可以防止由于人员变动导致某一功能模块无人熟悉的情况。而且pair可以提高代码的质量，两个人总是比一个人的思路要广泛，发现问题的可能性也大得多。
  但是pair programming 也有其无法避免的弊端。
  pair programming 一般要求两个人中至少有一个具有pair经验， 要知道，一个人coding的时候可以只顾自己的思路，两个人的话，你不但要有自己的思路，还要思考别人的思路，这需要极大的耐心去兼顾别人的想法。
  举一个简单的例子，当两个人fix bug的时候， 两个人很可能有不同的思路来探索bug产生的原因，而且这时候很难说谁对谁错，如果两个人都以自己为中心，尝试自己的想法，那就会发生抢鼠标的情况，这是最不愉快的。
  和fix bug很相似，当做某些research的工作的时候，很可能N个思路都可以达到目标，而且讨论谁的思路正确也会无果而终。这时候就不适合pair programming。
  现在回顾一下最好的pair 方式是什么呢？ 一个人写测试，一个人写实现。不会有什么冲突，为了实现一个目标各有分工。另外就是对系统做较大的改动的时候需要share这个改动的信息，这时候可以pair。 但是只要是做类似research的工作的时候，就不适合pair，这时就需要独立思考。

  做了pair不到1年，我感觉只要是research的工作，而且2个人都有不同的想法，这时候就可以不pair。
  如果是做新的story，对系统有较大的改动，就需要pair。
 
  pair之所以很难推广，是因为在开发的过程中，大部分的时间都是做research， 因为在动手之前，首先要知道相关的功能是如何运作的，所以就会反复的看代码。
 
  另外，从绩效考核的方面说，如果到了一段时间就要考核dev的performance，而且考核结果和奖金挂钩，那就热闹了， pair的两个人肯定会抢着做story， 谁都不想让出主力的位置，要知道，一旦让出主力位置，你就有可能被拉开差距，对系统的熟悉程度也会降低。那最后你的绩效也会不好。如果两个人抢着干活，就很容易出现rush的情况，做出来的东西有可能是没有经过深思熟虑的。

  有的dev能力可能很强，可能说：“我不会跟我的pair抢着coding...”，这可能是因为他的功力比较深，对类似的系统已经很熟悉。但是这样的人又有多少呢？ pair要想很好的推广，就要考虑大部分dev的情况。

  所以，pair的利弊和实施的时机就是上述我说的。以后要是哪一个人说：“诶？ 你们怎么没有pair啊，这样不行啊！”。 那么我会说：“玩儿蛋去， 谁告诉你任何时候都需要pair啦”

评论

33 楼 case0079 2009-03-10  

关键是平时多交流,多沟通.
如果因为2个总比1个好
那你还不如来个GROUP CODING呢.
这样有实际意义吗?

32 楼 抛出异常的爱 2009-03-09  

mock1234 写道

抛出异常的爱 写道

人是有弹性,可压缩的.摆在合适位置,他会干活,摆在不合适的位置 挤挤总会有的.

听起来好象是民工头。

你不认为很多公司都是这么作的么不止是软件公司.

31 楼 抛出异常的爱 2009-03-06  

人是有弹性,可压缩的.摆在合适位置,他会干活,摆在不合适的位置 挤挤总会有的.

30 楼 gigix 2009-03-06  

robbin 写道

我不想做口舌之争，何况你举一个例子也说明不了什么问题，我也可以举出来一个从T公司出来在D公司推行PP却一直很不成功的例子，当然你可以归结到这个从T公司出来的人不知道方法和技术上。

你说“你不能在招聘环节去挑选气质一样的团队成员的话，pp必然失败”。

从逻辑的角度，哪怕你举出一千个例子也证实不了你这个全称描述，而我只要找到一个反例就能证伪它。就好像你说世界上没有黑天鹅，你找出一千只白天鹅也证实不了这个命题，只要一只黑天鹅出现就能证伪它。

H公司和T公司的员工能成功结对，我觉得是一个显而易见的反例，足以证伪你这个“必然”了。

从做事的角度，我觉得，把工作上的失败，归结到这种明显不能以工作的方式解决的气质问题，而不是去找出真正的问题所在并解决它，是一种推卸责任和逃避。固然，可以让脆弱的小盆友们感到轻松些。

29 楼 robbin 2009-03-06  

gigix 写道

robbin 写道

pp有一个不可或缺的前提条件：团队成员之间要有高度的认同感，否则pp就是扯淡！

ThoughtWorks的pp搞的那么好，其根本原因在于ThoughtWorks招聘环节当中有一要求：你未来的同事来面试你，challenge你，看你能不能和他们臭味相投，他们看你顺眼不顺眼，如果不能的话，对不起，你再优秀，也要被拒！所以你可以观察到 ThoughtWorks的这些员工很抱团，一个鼻孔出气，文化气质都比较趋同。这是pp成功的先决条件。（当然也有一些人因为这种莫名其妙理由被拒后，会感到愤愤不平，不能够忍受ThoughtWorks的傲慢）

反观国内很多公司的技术团队，作为一个工程师，你没有权利拒掉一个你看不顺眼的候选人，特别是你不能够以看不顺眼一个人来拒掉他。有时候人和人之间的感觉是很微妙的，你要是看不顺眼一个人，你自己都未必说的出来是什么理由。但是你要真和一个自己看不顺眼的人pp，还真就没有办法合得来，所以pp的成功与否不在于两个人水平差异，而在于性格差异和兴趣差异。你不能在招聘环节去挑选气质一样的团队成员的话，pp必然失败。

照你这么说，以加班跳楼闻名的H公司，居然大半员工也有着和T公司一样的气质呢
不然为什么我们跟他们能成功结对到一起去？

有些事情，你没有做好，可能只是因为你不知道方法和技术
太轻易的把失败归结到气质这种看不见摸不着的东西上面，好吧，可以很容易的让自己感到愉快，也不错

我不想做口舌之争，何况你举一个例子也说明不了什么问题，我也可以举出来一个从T公司出来在D公司推行PP却一直很不成功的例子，当然你可以归结到这个从T公司出来的人不知道方法和技术上。

28 楼 gigix 2009-03-06  

robbin 写道

pp有一个不可或缺的前提条件：团队成员之间要有高度的认同感，否则pp就是扯淡！

ThoughtWorks的pp搞的那么好，其根本原因在于ThoughtWorks招聘环节当中有一要求：你未来的同事来面试你，challenge你，看你能不能和他们臭味相投，他们看你顺眼不顺眼，如果不能的话，对不起，你再优秀，也要被拒！所以你可以观察到 ThoughtWorks的这些员工很抱团，一个鼻孔出气，文化气质都比较趋同。这是pp成功的先决条件。（当然也有一些人因为这种莫名其妙理由被拒后，会感到愤愤不平，不能够忍受ThoughtWorks的傲慢）

反观国内很多公司的技术团队，作为一个工程师，你没有权利拒掉一个你看不顺眼的候选人，特别是你不能够以看不顺眼一个人来拒掉他。有时候人和人之间的感觉是很微妙的，你要是看不顺眼一个人，你自己都未必说的出来是什么理由。但是你要真和一个自己看不顺眼的人pp，还真就没有办法合得来，所以pp的成功与否不在于两个人水平差异，而在于性格差异和兴趣差异。你不能在招聘环节去挑选气质一样的团队成员的话，pp必然失败。

照你这么说，以加班跳楼闻名的H公司，居然大半员工也有着和T公司一样的气质呢
不然为什么我们跟他们能成功结对到一起去？

有些事情，你没有做好，可能只是因为你不知道方法和技术
太轻易的把失败归结到气质这种看不见摸不着的东西上面，好吧，可以很容易的让自己感到愉快，也不错

27 楼 robbin 2009-03-05  

pp有一个不可或缺的前提条件：团队成员之间要有高度的认同感，否则pp就是扯淡！

ThoughtWorks的pp搞的那么好，其根本原因在于ThoughtWorks招聘环节当中有一要求：你未来的同事来面试你，challenge你，看你能不能和他们臭味相投，他们看你顺眼不顺眼，如果不能的话，对不起，你再优秀，也要被拒！所以你可以观察到 ThoughtWorks的这些员工很抱团，一个鼻孔出气，文化气质都比较趋同。这是pp成功的先决条件。（当然也有一些人因为这种莫名其妙理由被拒后，会感到愤愤不平，不能够忍受ThoughtWorks的傲慢）

反观国内很多公司的技术团队，作为一个工程师，你没有权利拒掉一个你看不顺眼的候选人，特别是你不能够以看不顺眼一个人来拒掉他。有时候人和人之间的感觉是很微妙的，你要是看不顺眼一个人，你自己都未必说的出来是什么理由。但是你要真和一个自己看不顺眼的人pp，还真就没有办法合得来，所以pp的成功与否不在于两个人水平差异，而在于性格差异和兴趣差异。你不能在招聘环节去挑选气质一样的团队成员的话，pp必然失败。

26 楼 gurudk 2009-03-05  

不管怎么说，Pair的好处是显而易见的，具体用的好不好，依赖与使用者的上下文和使用者的应变能力了，没有银弹。

25 楼 抛出异常的爱 2009-03-05  

黑男爵 写道

"最好的pair 方式是什么呢？ 一个人写测试，一个人写实现。不会有什么冲突，为了实现一个目标各有分工。"
LZ的这句话，说的不错。
pair programming并不适用与软件开发过程中的任何阶段，并且就我个人来说，我觉得如果让一个老手与一个新手搭配做pair，肯定效率并不会提高，反而可能会导致进度拖延的问题。不过，让两个有同等经验的人去做pair，感觉上又会是一种资源的浪费啊。

把脑子当作定大小的内存.
两个脑子当作两台电脑上的内存.
除了算法问题外.
两台机器内存会扩大 一倍.

参考memcache

24 楼 黑男爵 2009-03-05  

"最好的pair 方式是什么呢？ 一个人写测试，一个人写实现。不会有什么冲突，为了实现一个目标各有分工。"
LZ的这句话，说的不错。
pair programming并不适用与软件开发过程中的任何阶段，并且就我个人来说，我觉得如果让一个老手与一个新手搭配做pair，肯定效率并不会提高，反而可能会导致进度拖延的问题。不过，让两个有同等经验的人去做pair，感觉上又会是一种资源的浪费啊。

23 楼 wym0291 2009-01-21  

实践过pair，谈谈感想：

首先，不要老是用比较古老的pair方式。。。。现在的pair是可以2个人坐在一张桌子上，面对着各自的电脑（不是一个电脑），通过IDE联线支持，同时编辑一个文件，顺便聊着天。如果离的远可以开着视频。这些google的工程师不是发布了一个视频示范过嘛。

其次，如果2个人水平比较接近，很容易迸发奇思妙想。如果2个人水平都比较菜，速度放弃pair。。。。。

22 楼 jiangshaolin 2009-01-20  

我还以为是练<<玉女心经>>,要两个人心心相通.汗!!

21 楼 photon 2009-01-06  

robbin 写道

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

jianfeng008cn 写道

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

20 楼 seemoon 2009-01-02  

我没有看到pair coding(or programming?)的精神和价值，相反，我看到了人性的虚伪和自私。

19 楼 Gavin.Chen 2008-12-21  

本人毕业前都是自己独立做网站，做了一年多

后来去一家公司实习，带了几个只是在学校里学会了点C的人开发一个网站，做了半年多

毕业后，离开实习的公司，一直到现在，一年半的时间里，都是在结对编程

技术总监是个技术牛人，近二十年的编程经验，一直与国外的一些技术精英有着交流，他非常推崇极限编程，公司也一直在采用结对编程。

他始终认为，结对编程的话，一些像NullPointer之类的基本bug是不可能会出现的，除非是一个人偷懒，结对编程能尽可能多的节省调试bug的时间，因而能大大提高开发效率，并且从带新人方面，能快速地使新的员工的技术水平得到提升，并且能使更多的人熟悉系统，从而可以防止因为某个员工的变动而出现断层。这些大多都是极限编程所表述的内容。

但从这一年多的开发中，我有以下的一些看法

首先是优点。
1）假如结对编程中并且都是善谈的人，结对编程的效果可以较好地呈现，大家都互相地分享经验，可以更好更快地让新员工提升自己的能力，这都是有目共睹的

2）假如结对编程的两个人都可以保持高度的精神集中，开发中将能大大地发现一些错误，从而将这些错误在开发的阶段就可以fix，避免了无谓的debug

3）假如在结对编程中，两个人都始终保证对系统的熟悉，那么其中一个员工发生变动，对系统的影响将可以减少至最少

4）假如员工都有差无私奉献的态度，那么团队互相之前的经验分享将变得非常和谐，大家都能学习到其它人所发现的新鲜的玩意

5）假如结对编程的两人水平差不多，那么互相提意见，将会大大地扩展两人的视野，另一人总会表达自己的一看法与建议

6）其它假如这里就不一一列举了

然后就是缺点
1）假如结对编程中两个都不是健谈的人，或者说一新一老员工时，老的员工不健谈，那么自始至终，就会有一人始终保持着被动，看着另一个人不断地拉动滑动杆，切换代码，很快，这个人就必须得靠咖啡以保持自己的眼睛不闭上了，如果你说他不善谈的话，请来干嘛，问题是，事实上公司不可能保证每个请来的人都是非常善谈的，假如还要以假如作为保证，那么效果也只能假设了，见过很多的例子就是，一个较熟悉系统的人，带着一个新人，结果新人跟了他几个月，结果系统一点也说不上了解，反而连一些最基本的代码也写不出来

2）假如结对编程的Navigator不能保持精神集中，那么他的作用就基本会降至非常低的水平，即他会白白地拿工资，而不用干活了，代码始终变成一个人写，另一个人白看，一个人干两个人的活，手累，心更累，怎么能保证每个人在每天都保持高度的集中，这是不可能的事，等程序出了低级错误，再去追究当时的Navigator的错误？这就等于对结对人两个进行挑拨

3）假如在结对编程中，一个熟悉系统的老员工带着一个新的员工，在过了一段时间后，老员工因为某些原因缺阵，新员工仍然需要很多的一段时间，才能熟悉系统，因为他们从老员工学到的，只是在这段时间里，一起做过的一部份代码，如果他们在一起的时候一直在做bug fix，那么这个新员工所接触到的部份就可以说可以不必提了

4）假如员工都那么无私，这个假设成立的几率太低了，结对编程中，一个人的自私，将会引起另一个人的自私，分享将成为障碍，一起坐在一台电脑前，缺有着暗斗争，这样真累

5）假如结对编程的两人水平差不多，在结对编程一段时间后，差距就会被慢慢拉开，于是一个人都会成为主导，另一个人由于慢慢地插不上嘴，会变得越来越没自信，慢慢地主导的人就会抱怨同伴不帮自己解决问题，变成一个人编写代码，一个人养两个人，累，于是主导的人不得不想怎么去偷懒

当然还有更多的点可以说，这里就不详提了，相信做过结对编程的人都会有深刻的休验


据我所知，结对编程，最初只是以学校的学生进行了实验，而得出的原型，在实践中，缺陷还是太多太多，不能盲目一味推崇

总而言之，个人认为，在适合的时候进行结对编程，效果非常好，就比如本人现在带着几个新人，首先pair几天，然后分享一些任务让他们独立去完成，然后隔一段时间去询问进度，如果发现他们有不能解决的问题，再短暂pair一会，帮他们解决问题，分析原因给他们听，这样自己就可以将一些琐碎的东西，当成给他们的练习题，自己则可以专注于框架方面研究，他们也可以在自己的思考中快速进步。但如果盲目跟从，全盘肯定结对编程，这样不但起不到应有的效果，而且会大大打击员工的积极性

18 楼 xin911 2008-12-08  

rocwon 写道

抛出异常的爱 写道

coding是最没有技术含量的活.
没有价值,没有必要花二个人来作

有价值的是设计,客户需求预测(这个跟算命很像.),重构.代码走查.文档编写
想想对日外包(中国N百人开发,日本N十人写文档)

--------------
没价值? 难道你交付给客户的是需求,是文档,是代码走查报告?
你就忽悠吧. 总能见到说看不起编码工作的一类人代码写得丑陋之极.

--------------
Pair的实践并不是单独存在的，还有其它best practice与其配合, 才会产生一个整体的效果

不管怎样我觉得老抛这次的话还是很中肯的。

站的角度不同的关系，明显老抛是在从程序员的角度上考虑，为程序员着想。coding的比重要小一些。最初的设计决定最终的代码实现，如果coding更重要岂不本末倒置！只是看那条路更适合年龄越来越大的程序员。

你是站在公司老总的角度上看问题的，作为公司老总着想的。恨不得连文档说明都没有，是为了节约公司成本（包括程序员），连代码都不用，直接交war包什么的得了。

对日外包还是看侧重点吧。对于文档，管理，review，test，coding的流程确实比较严格。学60-70%就好了。之后看自己的侧重点。就算是大公司，水平良莠不齐能急死人。可以想想一下那些毕业之后就进日企干3~5年的，有的think in java都没看过，review代码的时候逻辑是日本人的，剩下的代码结构就是自己的“创造”了。时间久也是一塌糊涂。所幸在那里接触了2个以前没有接触过的框架和一些流程什么的。干了3年，刚刚起步的新手说。

17 楼 抛出异常的爱 2008-12-08  

rocwon 写道

抛出异常的爱 写道

coding是最没有技术含量的活.
没有价值,没有必要花二个人来作

有价值的是设计,客户需求预测(这个跟算命很像.),重构.代码走查.文档编写
想想对日外包(中国N百人开发,日本N十人写文档)

--------------
没价值? 难道你交付给客户的是需求,是文档,是代码走查报告?
你就忽悠吧. 总能见到说看不起编码工作的一类人代码写得丑陋之极.

--------------
Pair的实践并不是单独存在的，还有其它best practice与其配合, 才会产生一个整体的效果

你软件的时间大多数用在哪里?
如果有一半时间用来coding的话算我没说.

16 楼 rocwon 2008-12-08  

抛出异常的爱 写道

coding是最没有技术含量的活.
没有价值,没有必要花二个人来作

有价值的是设计,客户需求预测(这个跟算命很像.),重构.代码走查.文档编写
想想对日外包(中国N百人开发,日本N十人写文档)

--------------
没价值? 难道你交付给客户的是需求,是文档,是代码走查报告?
你就忽悠吧. 总能见到说看不起编码工作的一类人代码写得丑陋之极.

--------------
Pair的实践并不是单独存在的，还有其它best practice与其配合, 才会产生一个整体的效果

15 楼 puroc 2008-12-07  

jobs 写道

pair coding又称断背山编程，是受到同志们广泛欢迎的coding方式！

头一次听说，真搞笑，哈哈哈！

14 楼 hmilylxs 2008-12-05  

我猜会不会跟做人有关，如果大家都真心为team着想，为项目着想，只要找到一个平衡，那么事情就好办了