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