自打XP提出pair programming来，在学术界也不乏讨论。 今天就让我们来研读两篇pair programming的学术论文。
[1]The Costs and Benefits of Pair Programming 发表于 2000年 Proceedings of the First International Conference on Extreme Programming and Flexible Processes in Software Engineering， 出自 agile的先驱者（个人认为是鼓吹者） alistair cockburn的笔下 该文得出7点pair programming的好处是
- many mistakes get caught as they are being typed in rather than in QA test or in the field (continuous code reviews);
- the end defect content is statistically lower (continuous code reviews);
- the designs are better and code length shorter (ongoing brainstorming and pair relaying);
- the team solves problems faster (pair relaying);
- the people learn significantly more, about the system and about software development (lineof-
sight learning); - the project ends up with multiple people understanding each piece of the system;
the people learn to work together and talk more often together, giving better information
flow and team dynamics; - people enjoy their work more.
同时对于时间的cost是 15% more 而不是预期的100% more. 但这15% 会在以后的QA和后期维护中抵销掉。
我比较在同1，5 ； 怀疑2，3， 4； 对6持保留态度，彻底反对7。
2,3 是要depend on 人的智商和经验的。4. 如果两个新手pair，或是一高一低，显然速度没有高手快。6，虽然正确，但是我持保留态度，一方面原因是job security，毕竟我们都是打工的，如果把developer都当作hot swapable的component，个人觉得太残酷了，一个process不能体现人性化的一面 （你随时可以走人哦，我们这回这东西的又不只你一个）的practice是不能让people enjoy的。当然信任都是相对的, 如果一个资本家认为layoff的成本是0， 你说他会怎么做。 另一方面为了lay off cost是0 去做到multiple people understanding each piece of the system本身就是一个high cost的事情。
[2] Are Reviews an Alternative to Pair Programming 发表于 2004年的 Empirical Software Engineering 该文得出的结论是
- A pair of developers does not produce more reliable code than a single developer whose code was reviewed.
- Although pairs of developers tend to cost more than single developers equipped with reviews, the increased cost is too small to be seen in practice
我的几个挺 XP 的朋友看了该文, 觉得是胡扯，但是它们本身是没有try过 code review的。 不过这个结论似乎也算是皆大欢喜型的。 pair == solo+review。 我个人的经验就是pair有时候缺乏review, 有时候findbug, PMD这些工具对programming的帮助比pair的更大
[3]Effects of pair programming at the development team level: an experiment 发表于 2004年的 Empirical Software Engineering该文 研究了 productivity, defects, design quality, knowledge transfer and enjoyment of work 得出的结论是
Pair programming increased the development effort of the first tasks considerably compared to solo programming, but later the differences were small .
Due to this learning time the pair programming teams had worse overall project productivity .
Task complexity did not affect the effort differences between solo and pair programming .
The pair programming teams wrote code with fewer defects, but were less careful in system testing, and therefore delivered systems with more defects . They may have relied too much on the peer review taking place during programming.
Knowledge transfer seemed to be higher within the pair programming teams.
Finally, we also found weak support for higher enjoyment of work in the pair programming teams .
[4]Evaluating Pair Programming with Respect to System Complexity and Programmer Expertise 发表于 2007 IEEE Transactions on Software Engineering 33(2):65-86 这篇文章对295个java professional做了一天的实验 最后得出的结论 do not support the hypotheses that pair programming in general reduces the time required to solve the tasks correctly or increases the proportion of correct solutions. 同时为了正确地完成task，需要有84 percent increase in effort。
学术界对pair programming也是褒贬不一的，有时候不同的论文和试验模型可以得出完全不同的结论， 所以很难从某种绝对的角度上讲pair programming优越于solo programming。 Pair or not pair, 我看还是取决于个人，团队和项目吧，把pp当作救命稻草只会误人子弟。 从根本上人性化的解决developer所需才是硬道理，google在这一点上做得很不错。