关于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啦”

评论

13 楼 wiwolf 2008-12-04  

pair的关键还是看pair的人互相之间是否可以配合默契，两个pair的人在技术上一定要比较接近的才行。配合好就没问题

12 楼 抛出异常的爱 2008-12-03  

程序员与代码工的区别
程序员会把工作量下降下降再下降.降到最小
代码工,把设计,转码成源代码.

你们公司大多数人是程序员,还是代码工?

11 楼 sg552 2008-12-03  

可是，从你的帖子中，我觉得你说的 coding  就是coding的意思啊。

另外，我前面的帖子中的红色引用，我觉得是不正常的政策和方法所导致的。

10 楼 liano 2008-12-03  

先排除一下歧义， 我上边的coding就是programming的意思。怪我用词不准

9 楼 抛出异常的爱 2008-12-03  

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

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

8 楼 sg552 2008-12-03  

抛出异常的爱 写道

liano 写道

gigix 写道

我觉得吧，pair coding和pair programming，一字之差，就已经足以说明问题了。

不明白，老熊说得再详细一点吧

大概想说 coding的价值太低不值得pair

看了几遍大家的回帖，我觉得楼主的 coding的意思，指的仅仅是敲代码，而且敲的是 source code. TestCase不算。
如果楼主的公司的绩效考核，不包括单元测试，硬要把两个人完成的一个story算成其中一个人的工作量的话，就有
破坏结对的嫌疑。

而 pair programming, 不但包括了 coding, 还包括分析，编写用例，单元测试，重构，设计，持续集成等等其他的方面，有必要的话甚至还要在项目交接时写个文档或者做个视频说明。

liano 写道

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

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

我觉得，你们公司所实行的pair，不是很正确的。甲先根据story写出个TestCase，然后乙来实现这个方法。过一会儿乙累了，两人调换位置。等这个story做下来，甲乙两人都有份，对代码都一样熟悉。 怎么能出现 “主力”，“拉开差距”，“抢着coding”呢？

7 楼 liano 2008-12-02  

gigix 写道

liano 写道同意你关于绩效的观点，但是这种“一荣俱荣，一损俱损”的办法又有多少公司实施呢？基本上很多公司到年底都会有个人的performance review，所以绩效的问题要公平的话，比较难。
一个很简单的道理
如果你在一个团队里工作，如果这个团队里每个人都认为你应该滚蛋
那么你就应该滚蛋，不论到底你是傻逼还是他们都是傻逼

换句话说，如何pair取决于整个团队，取决于dev的感觉，如果大多数人觉得写story的时候pair的价值比较大，而到项目后期pair的价值不大的话，那到后期就可以不pair。

6 楼 gigix 2008-12-01  

liano 写道

同意你关于绩效的观点，但是这种“一荣俱荣，一损俱损”的办法又有多少公司实施呢？基本上很多公司到年底都会有个人的performance review，所以绩效的问题要公平的话，比较难。

一个很简单的道理
如果你在一个团队里工作，如果这个团队里每个人都认为你应该滚蛋
那么你就应该滚蛋，不论到底你是傻逼还是他们都是傻逼

5 楼 抛出异常的爱 2008-12-01  

liano 写道

gigix 写道

我觉得吧，pair coding和pair programming，一字之差，就已经足以说明问题了。

不明白，老熊说得再详细一点吧

大概想说 coding的价值太低不值得pair

4 楼 liano 2008-12-01  

gigix 写道

我觉得吧，pair coding和pair programming，一字之差，就已经足以说明问题了。

不明白，老熊说得再详细一点吧

3 楼 liano 2008-12-01  

魔力猫咪 写道

结对编程是一个比较特别的编程方式。很多人说它好，也有人讨厌它。不过可以肯定的是，如果结对良好的话，肯定是效率要高于不结对的。不过人和人不一样，结对不是所有人都适用，而且还有一个结对方法是否正确的问题。
所以不要因为某些结对尝试失败就一棍子打死。
还有所谓绩效问题。这个其实是个团队毒瘤。《人件》中就对此进行过探讨。在团队中推行所谓的绩效，其实根本不能做到提升动力的作用。反而会造成问题。比如你说某人好，我却确觉得它不好。正好我编码的地方比他的难，所以慢了。你却认为我没完成，我当然不满意。这些东西绩效很难处理。而且现在很多公司都是不公示的，你很难知道同事拿多少钱。这样绩效有意义吗？我干好了也未必比别人多。
我觉得应该突出团队概念。一荣俱荣，一损俱损。团队好了，大家都有钱拿。整个项目上不去，大家都有责任。

同意你关于绩效的观点，但是这种“一荣俱荣，一损俱损”的办法又有多少公司实施呢？基本上很多公司到年底都会有个人的performance review，所以绩效的问题要公平的话，比较难。

2 楼 魔力猫咪 2008-11-14  

结对编程是一个比较特别的编程方式。很多人说它好，也有人讨厌它。不过可以肯定的是，如果结对良好的话，肯定是效率要高于不结对的。不过人和人不一样，结对不是所有人都适用，而且还有一个结对方法是否正确的问题。
所以不要因为某些结对尝试失败就一棍子打死。
还有所谓绩效问题。这个其实是个团队毒瘤。《人件》中就对此进行过探讨。在团队中推行所谓的绩效，其实根本不能做到提升动力的作用。反而会造成问题。比如你说某人好，我却确觉得它不好。正好我编码的地方比他的难，所以慢了。你却认为我没完成，我当然不满意。这些东西绩效很难处理。而且现在很多公司都是不公示的，你很难知道同事拿多少钱。这样绩效有意义吗？我干好了也未必比别人多。
我觉得应该突出团队概念。一荣俱荣，一损俱损。团队好了，大家都有钱拿。整个项目上不去，大家都有责任。

1 楼 gigix 2008-11-13  

我觉得吧，pair coding和pair programming，一字之差，就已经足以说明问题了。