对于结对编程我有疑问

对于结对编程我有疑问：
实际编写代码的人总是对代码的结构和功能、细节更清楚一些，而观看的人总是很难同编写者一致，第一天差别也许并不明显，但是第二天、第三天....一个月之后呢，对于简单的项目也许没有什么，但是对于复杂的算法和复杂的对象调用关系、对象的状态等问题，这种差别就非常明显了。
请在实际项目中使用结对编程的同仁谈谈自己的感受，尤其希望有处理复杂逻辑经验的同仁不吝赐教。

敬上。

汗，为什么xp要强调结对编程呢？
仅仅是让一个人看么？

对于你的第一句话，简单地说：结对，双方的位置是对等的，可能一会儿甲写代码乙看，下一会儿乙写代码甲看的。而且也不一定要相同的两个人一直结对下去，都是可以换的。
你对一些基本概念的理解可能有一些偏差。
其他的就不多说了。
多找一些相关的资料看看：）

试过一阵子........一个字，爽。。。。严严重支持，比如，我在看时，我会看出一些错误，需要停下来修改这些错误时，我就会喊stop...需要继续下一个比较重要步骤时，我们会停下来讨论方案。

在园区有时候路过一些软件公司,看到里面开发人员正儿八经的坐在安静明亮的用隔板隔开的办公室里认认真真一丝不苟全神贯注工作的场景...心里不禁暗喜:结对好,结对妙,结对呱呱叫!--虽然我们没用xp

复杂的对象调用关系看不懂我想也许是因为读码能力差，也许是因为代码编写的就让人看不懂，当然也有可能是别的原因。
我想读码能力和编写高质量代码完全是一个程序员素质，可能说明要结对编程，就得整个团队都有这种素质，不是新手能做的。

你要是写的代码同伴都看不明白，我想你的味道就太浓了。

在XP的核心实践中，结对编程是我执怀疑态度的一个，当然，我的怀疑不是说XP的创造者们是拍脑袋出来的，而是怀疑它在中国，在中国软件企业可以实施的现实程度。
    结对编程的初衷是什么？两个人一起写代码，一起理解代码，防止代码出现味道？通过多交叉的结对编程，实现代码的共通（不只是共同拥有，而是共同理解），同时也可以起到对规范的遵守？抑或，还有其他？
    但是我对那样的一种工作环境始终保持疑问的，我就列出几种环境，看看是否有网友可以帮忙理清：
1. 假设项目不是新做的，或者说中途有人离开团队，或者说结对编程的其中一个成员是后加入的，这样的情况在软件企业是非常非常常见的，这样在结对编程的两个成员中水平、理解力、熟悉程度在出现较大差异的时候，如何保证结对编程的质量。
2.如何保证结对编程的两个人中坐着的那个人能保持高度的专注力和责任度?每一个程序员都有过这样的经验，一起坐在一台电脑前解决一个问题，但这是偶尔的，如果连自己的电脑都没有，每天大部分时间就和另外一个程序交换着电脑，能一直保持高注意力。再说，中间有个什么事情（比如会议、打扰甚至上洗手间）离开一个人，回来后，不是还要回头去理解别人写的代码么？
3.在稍微一个大的软件公司，对于配置管理都是相当看重的，基本上不允许哪个程序员可以看到和拥有所有的代码（就中国这点知识产权的保护意识，和国外是非常的差别），并且对于员工的绩效考核也都是基于负责模块的表现（比如说代码量，bug数，以及复杂度等等），结对编程在实施上就存在一点权责和利益的的问题了。
4.另外，结对编程，在每一时刻都是一个程序员在编程，说效率如何高，也只是1+1>1，但是否大于2呢？中国软件企业的项目，多半的规模是在10人以下（程序员部分），而完成的代码量都是相当大的，所以加班现象很多，在如此情况下，实施这个实践，难不成要double的人力资源？
5.最后，就是和XP的另外一个实践的冲突（个人理解），也就是代码重于设计，我不太清楚基于XP的工作模式，是怎么做设计工作的？是通过某些CASE工具，如rose/together来进行设计和编码的相互切换（也就是边设计边编码），还是直接就在IDE上进行编码？我们知道，有些模块和重要内容，不是简单一两个类或者一两个模式组合就可以解决的，中间要用到很多的设计的思想和步骤，并且每一个程序员都有过这样的经验，设计是跳跃的，不是循序渐进的。连自己也不知道下一步会想到什么（这就是为什么程序员是需要创造性，工资高的原因之一），更何况坐在边上的人？难不成在这样的情况下，编码的人还要停下来，去解释自己暂时也不是太清楚的过程的想法？
    也许偏颇，但以我个人的经验，我认为结对编程只能在有限情况下进行实施，并不如XP中所描述一样前景异常美好。

凤舞凰扬, 我理解结队编程应该是:

Hi, 我这有问题, 可以帮忙看一下吗?
没问题, 马上就到.
然后显示问题,讨论, 试探, 解决, 各回各家.

关键是: 随时提供帮助成为一种文化和习惯.  而不是偶发事件.

我觉得xp 致力于一种共同成长的学习型组织. 这样的组织文化我想在国内肯定特别的少.  营造这样的组织文化应该是很困难的. 可能太悲观.

对于凤舞凰扬的疑问，我可以试着说明一下我自己对于结对编程的理解，首先要说明的是，个人认为结对编程是一种很不错的实践，不过要获得好的成绩要具备了一定的条件才可以

结对编程不是说结对的成员一直在一起工作的，而是每隔一段时间（很短的时间，甚至有可能是一天）就互换同伴，这样可以保持工作的高度集中和每个成员对于整个项目的把握。其实，结对编程中的成员水平应当在相差不大的档次上，要么就会像楼主所说的出现质量问题。



呵呵，这里要说明的是，结对编程这个实践要求成员必须要有高度的专注力。在和同伴一起工作时，必须保持你的思维一直高度集中，如果这样不行的话那么代码质量还是会下降。这也是为什么XP提倡每周只工作40个小时，而且要求工作环境中要有设置完备的休息室（这个休息室我想国内可能没多少公司会实现，口水ing）的原因。没办法，这个实践对于体力的要求实在是太高了。至于同伴的事务以及休息时间，其实没有必要两个人一直在一起，可以两个人制定一个目标，可以在很短的范围内完成，比如一个小时，这个目标一旦实现，就可以休息一段时间。同伴有事需要离开的时候，可以找其他人看有没有空闲或者干脆休息好了。


对于配置管理的问题，我也不是特别清楚。因为XP提倡代码共享，提倡每个成员应当把握整个项目的进度，对于项目有着比较深的了解。其实XP本来就只适用于小型团队开发，如果是大型项目的话还是不要用XP的好。至于员工考核的部分，记得CMM顾问给我们培训的时候也提到过，不要把员工的绩效和代码量，bug数等等因素挂钩，这一点特别重要。因为每个人都有各自的情况，甚至于每个人不同天都有不同的情况，对于软件开发来说，只能对于组织或者项目进行量化来进行SPI，来检讨运行中的问题。最好不要把这些因素用来评价员工的绩效，因为这些因素本身就包含了很多不可预测的因素，一旦出现一些问题的话，很容易就会打击员工的积极性。



结对编程的效率超乎想象，很容易就可以出现1+1>2的情形。因为两个人同时参加编程，就等于已经有了一遍代码评审，实际上pass around的评审方式就是这样进行的。这样情况下出错几率就降低了很多，有效的减少了bug的产生。这样的话下面的一系列的流程都可以少很多工作量，比如测试，比如bug tracking。着眼于整个项目来看，这个实践确实大大提高了效率。至于加班，XP中不提倡加班。仔细想想，其实项目的很多时间都花在了修正bug和测试上面，如果从根本上就降低了这种情况的可能性，那么效率是不是就提高了很多呢？




先说明一点，我对于各种CASE工具没有什么好感。因为生成漂亮的图对于我们没有什么实际的用处，图是用来交流的，不是用来看的。可以两个人讨论来进行一个功能的实现，可以借助一张纸，或者白板，或者什么东西。只要可以明白对方的意思就可以了。注意：结对编程中两个人的地位是相等的，而不是有主次之分。而且有什么想法通过交流后两个人都觉得可行，就可以写出测试用例，再来写出实现。如果先前的想法又问题的话，可以通过重构来改变代码的结构。所以这里提倡频繁运行测试，有了问题可以及早发现及早解决，重构也相对容易一些。对于到处充满了坏味道的代码，我想没几个人愿意忍受着痛苦去修改的。

最后，我想说的结对编程在握看来应该是一个很好的实践，至少从各位大师的书上看来如此。可是，真正实践起来需要一些条件的。我就试过一段时间，痛苦不堪。为什么，因为我的同伴根本不去思考，根本不和我讨论。这样的实践是没有一点用处的，只能说自己累的要命，做出来的成绩却是两个人的……不过，我就知道身边有成功的例子，唯一的坏处就是对体力要求太高，基本上周末也没什么力气加班了，因为根本就爬不起来。：）

pair　programming是有前提条件的：
首先团队的成员是要有xp思想和相近水平的．如果你的同伴不愿意交流或无法交流，pair　programming只有害而无益
第２，pair　programming不是８小时的，５个小时足够了．许多人在上班的时候总要花点时间上网看看文章看看资料的不是么．
如果满足以上条件，代码的质和量都会有比较大的提高．所以在实践xp的时候，不光要看它的practice，还要看它的context