困惑的结对编程？

我也这么认为，但是即便两个人的水平不一样，也很又好处：知识传递，这是我亲身体会的，尤其是在培养新员工的时候。
嘿嘿.......
只可惜能结对的机会没有你想象的那么多，所以嘛，就要把握好机会罗，当然，如果所有的东西由你掌控，或者你的老大接受你的建议，那你的机会当然多多的了啊

实际上，在我看来，只要能够帮助尽快的发现bug的，不管是什么方式，PP也好，还是其他的也罢，都已经大大的功臣的了，当然，应该还有其他的一些因素要考虑。我实在不愿意debug，因为debug太浪费时间了，何况即便你debug了，你也不一定能找出bug的所在。
     我还记得以前的很多时候，每次花了很久很久的时间debug的，到后面还是没有结果，问问旁边的同事，一起看看，OK，解决的爆快，然后就是大叫一句：郁闷，原来这样，然后同事笑笑：呵呵，当局者迷，旁观者清啊.
    我现在debug的时间已经比以前少了很多，因为我写测试，遗憾的是，还是看到很多兄弟整天在debug，我还是经常看到很多IDE（我们公司采用IDEA）上那个调试的蓝色背景在不端的往下滚......，我虽然喜欢蓝色，但是写代码的时候我还是更喜欢绿色，酷爱绿色条。  
    但从PP能够帮助我们降低bug数量上来说，我认为就已经很值得去实施它了。
     说实在的，我还是喜欢PP的，我就两次经历（实际上还算不上PP），但已经有了很多好处了，我更喜欢和MM一起PP......


引用daquan198163老兄的话：
我始终坚信，软件开发是一项伟大的、创造性的劳动，它应该是一件充满乐趣的事，同时给我们带来成就感和体面的收入；

程序员应该是一群快乐的家伙，每天享受着自己喜欢的工作，有足够的时间去打篮球、跟哥们儿喝啤酒、陪女朋友看电影；

是的，我们应该是快乐的。

dearwolf写道：
<table width="100%" bgcolor="red">
<tr>
<td>如果是研发性质的项目，结对编程就不适用了吧？</td>
</tr>
</table>

首先要说明，“结对编程”技术中的“编程”可以是软件开发过程中的任何一个阶段（设计、调试、测试，等等），而不是仅限于编写程序代码。也就是说，结对编程技术覆盖了结对设计、结对调试、结对测试等等各方面。事实上，结对还可以用于处理研发性质的项目，当你表示怀疑的时候，你可找找这方面的资料：
Auer,K.and Miller,R.(2002).Extreme Programming Applied;Playing to Win,Addison-Wesley.

PP应该更加适合研发型的项目。对于普通的开发项目，一般并不是非常合适。

2006年的12月至今，我在一间对于国内来说应该算是很大的软件公司里面实习（因为这间软件公司的开发人员将近600人）。在进到这间软件公司之初，我们并没有马上接手实际的生产项目工作，而是首先进行为期二个星期的基础的不能再基础的培训（每个公司有每个公司的选人准则）。在培训完之后，我们进入了实战能力的考核阶段。公司把我们这批实习生分成了几个小组，每个小组四到五个人，然后分别用SSH（Struts+Spring+Hibernate，SSH）实现一个论坛。在我所分到的那个小组里面，因为每个组员的能力都不相同，所以我们组在开发的过程中，当有一个组员解决不了一个问题的时候，通常他都会交给另外一个比较能力更强的组员去解决，而接手这个问题的组员则把他正在做的任务交给他。于是，在我们组里经常会出现交换开发任务的现象，而且所有的问题都被解决，不但如此，我们组的所有组员对这个论坛的每一个模块都显得非常熟悉，因为每个人都经历过每一个模块。
与结对编程类似，交换编程也是一个非常简单和直观的概念：两位或者多位程序员轮流开发同一个软件系统的同一个模块的不同阶段的任务。交换编程的方式更合适的说法应该是交换开发，这种方式不仅仅可以应用于软件项目，也适合其他研究开发型项目。

但是，当一种技术，或者理念，大家都不熟悉的时候，每个人都需要查很多资料，都需要google，这种情况下如何peer？

peer google :-,

一台电脑，每个人想看的东西肯定不同

呵呵，XP里面也提到，我们要有信心和勇气，要信任别人，信任你的同伴，你的搭档.PP也是一样，peer google吧，呵呵，可以一起看的啊。