[敏捷开发][结对编程(Pair Programming) ]

结对编程(Pair Programming)是一个编程模式(Programming pattern)。两个程序员并排坐在一台电脑前，面对同一个显示器，使用同一个键盘，同一个鼠标一起工作。他们一起分析，一起设计，一起写测试例子，一起编码，一起单元测试，一起整合测试(Integration Test)，一起写文档等。基本上所有的开发环节都一齐肩并肩地，平等地，互补地进行开发工作。
   
      结对编程不是一个人简单地看着另一个在做什么——在卓有成效的配对工作里，这两个合作伙伴常常工作在不同抽象层次，一个人关注的是为实现眼前目标而编写的代码的细节，而另一个人考虑的是更大的前景和下一步要做的事情，这两个人的角色频繁进行更换。这是一项高强度的、严密的，且常常令人疲劳的活动，但是能够创造出经过深思熟虑的高质量代码。

——Laurie Williams &Steve Hayes

本贴是关于敏捷开发－结对编程(Pair Programming) 的内容聚集的帖子。欢迎跟贴，提供：

1、结对编程相关的研究资料和资源

2、实施结对编程在国内或自己公司所遇到的阻力

3、实践结对编程时，遇到的具体问题

4、如何让我们的结对编程做得更好

5、对2和3问题的解决方案

说明：描述问题时，最好能给出具体的例子，这样讨论不会太偏向于理论研究。

评论

35 楼 qinysong 2006-09-24  

我把楼上各位对于结对编程的价值/好处归纳如下：

引用

1、培训：结对编程是进行全方位编程培训，涉及从开发方法，思维方式直至代码风格，开发习惯等编程的方方面面。这种方式可比那些XX培训班的效果要好得多。
2、沟通：通过结对编程，可以对开发人员的编码能力、沟通交流技巧、理解能力等有一个全方位的了解。谁有什么优点，什么缺点，都能在结对编程中一览无遗。
3、监督：人都有懒惰的时候，一不小心，就将鼠标从eclipse转到了firefox，而且很长时间回不来。但结对编程时，这种现象绝不会发生。
4、效率：因人而异，每个人的效率都不同，但大家普遍认同的是一天8小时，能有效率地工作4小时就算很不错了。但结对编程时，两个人的工作时间应该能达到6小时以上。关键人的精神状态会完全不一样，一天不做什么的事的，总是无精打采的，相反工作充分的人却是神采奕奕。

5、促进规范：对于原来经常讲的代码规范，往往没有有效的推进措施而只是依靠个人的自觉性，结对之后，为了有效地沟通，为了照顾后面的一双眼睛，就会更加注重所写代码的规范性。
6、提高质量：由于随时都可以站在不同的角度，所以可以使程序更正确、更严谨、更通用、更易于扩展等等，同时结对也可以提高了成员的优化意识，促进代码重构，使程序始终保持最好状态。
7、加快成长：通过结对之后，特别是频繁的轮换结对，可以使队员广泛的扩展思维空间、取长补短，对于个人（特别是新手）的成长将有一个加倍的效果。

有了这么多让人眼花缭乱的好处，那么在实施的过程中的问题呢，我也对楼上诸位的各种看法归纳如下：
１、结对双方水平不同，很难沟通；
２、结对双方步调不一致，出现“你累了吗？ 我们休息一下吧”等情况；
３、不适应，觉得后面总有一只眼盯着，感觉不自然，影响个人注意力集中；
４、领导看来，那两个家伙怎么一整天都在那边聊天啊。工作不饱和；
５、领导觉得成本高，原来只要一个人干的活现在怎么要两个人来做；
６、办公环境受限，没有开放的空间，活动不自如；

既有价值，又存在问题，我们怎么办呢，我觉得还是适度吧

34 楼 jxb8901 2006-09-23  

我在实践中直接感受到的结对编程的价值是：
1、培训：结对编程是进行全方位编程培训，涉及从开发方法，思维方式直至代码风格，开发习惯等编程的方方面面。这种方式可比那些XX培训班的效果要好得多。
2、沟通：通过结对编程，可以对开发人员的编码能力、沟通交流技巧、理解能力等有一个全方位的了解。谁有什么优点，什么缺点，都能在结对编程中一览无遗。
3、监督：人都有懒惰的时候，一不小心，就将鼠标从eclipse转到了firefox，而且很长时间回不来。但结对编程时，这种现象绝不会发生。
4、效率：因人而异，每个人的效率都不同，但大家普遍认同的是一天8小时，能有效率地工作4小时就算很不错了。但结对编程时，两个人的工作时间应该能达到6小时以上。关键人的精神状态会完全不一样，一天不做什么的事的，总是无精打采的，相反工作充分的人却是神采奕奕。

33 楼 qinysong 2006-09-23  

认识到上面一点，我感觉应该回到本贴的主题上了，结对编程如何实施，如何最大的发挥它的优势和控制它的劣势，如何得到项目组成员及上层的认可

32 楼 qinysong 2006-09-23  

在上面我所表述的对结对编程的看法，之后我感觉是不是有些过于强调XP的整体性了，是不是有些过于强调关键实践之间的依赖性、相关性了？他们之间真的需要那么依依不舍吗？

后来在我的blog中，有网友如下留言：

引用

提几点个人的看法:
1. 需求变化不大和时间比较充足, 应该也能够用XP, 我觉得并不矛盾. 当然对于大规模的项目, 使用XP的确会有点问题(可以分成小模块解决).
2. 结对编程对沟通价值的一个实践, 跟重构没有直接的关系吧.当然 结对编程有相互监督的作用. 我一个人写程序也经常重构, 是一个人习惯问题, 也许在些结对编程可以对此做监督.
3. 重构是对代码和设计的整理, 只要有写代码, 或多或少会做一些重构, 但我不明白"很成熟的设计，很稳定的架构"就不用写代码了吗? 除非写完就扔了的.
4. 结对编程在XP中, 也可以部分结对, 在添加新功能特性时最好是结对.

我觉得他的观点应该将我从对ＸＰ的整体强调中，稍微拉回来一些。

对ＸＰ的局部采用，比如在一个项目的关键部分先引入“结对编程”，先引入“测试先行”，必然是我们深入认识、体验、直至有效实施的一个过程，更何况我们的项目中已经存在一些ＸＰ实践的影子，比如我们很早就已经强调“代码规范”了。

下面是我回复网友的一段话，我觉得我的认识又有了一步的深入，准确的说是观点往回走了一步，眼前变得更广阔了。

引用

其实ＸＰ本身的产生也肯定不是通过理论公式一步推导得到的，而是在实践中逐步形成，如为了节省维护详细设计的不断变更所带来的开销，ＸＰ的先导们采用了“简单设计”的关键实践；当采用简单设计之后，为了适应需求的不端变化对系统结构的影响，便加强了“代码重构”的重视程度并提升到关键实践的地位；为了有效地重构，发现“结对编程”具有很大的价值；为了顺利地进行“结对编程”，发现“代码规范”不容含糊，同时发现“代码共同所有”也为结对编程带来很大的便利，因为它可以无缝地进行结对更换；等等。

此外在局部采用的时候，还是要留意其整体性，比如，如果我们忽略“小版本的短周期发布”，那么采用“计划游戏”将可能会很危险。

31 楼 抛出异常的爱 2006-09-21  

引用

判断我们代码需不需要重构，如果需要，结对编程就会提供很好的价值

厉害一句话改变了我的关点！

30 楼 qinysong 2006-09-21  

上面写得太多了，好像重点不太突出了，我觉得是不是采用结队编程，一条关键的依据是：
判断我们代码需不需要重构，如果需要，结对编程就会提供很好的价值，包括代码正确性、严谨性、可扩展性等等，为代码的重构提供很好的基础，并且结队编程克服不想对自己代码进行重构的惰性。
如果判断我们对系统架构设计，有很成熟的经验，且需求的变更不会对设计造成太大影响，那么结队编程就消弱了存在的意义。

如果旁边有感觉不错的搭档，对于新的、陌生的问题特别是算法，我喜欢一起进行讨论。
比如有一次，对一个正方形路径遍历的算法解决问题，在正方形内，每条路径从起点（0，0）到终点（n，n）沿着从右向左，或从下到上行进，需求所有路径坐标，我考虑可以把从右向左的一步用1表示，从下向上的一步用0表示，那么一条有效路径就是n个1和n个0表示的一个字符串。
但是我考虑怎么找出这些字符串来呢，这时我的思维进入了对这些0和1如何排列组合的思维空间，很难跳出来，这时我的同事说，“有了，可以从0开始数，到二进制的1..10..0所有二进制数中，判断1的个数，如果1的个数是n岂不就是要找的路径嘛”
呵呵，就这样问题解决了。

在一个人考虑问题的时候，起初他的思维可能会放的很宽，但是随着问题的深入/进展，他的思维会越来越集中在某一部分，通常我们说陷入牛角尖了。
所以我们经常会有这样的体会，我们去趟洗手间，或在回家的路上，我们突然就找到了某个刚刚还百思不得其解的很好的解决方案。

这也就是结队编程的价值，它使我们随时都站在两个视角，一个具体微观、一个粗放宏观。

29 楼 number017 2006-09-21  

gigix 写道

钱。
烂代码是要花时间来修的，bug是要花时间来抓的，code review是要花时间来做的，一个人独自干了一个月的活别人要花很长的时间才能弄明白，更何况说不定哪天这人就走了，花的时间就更多。时间都是要钱的。
这就是pair的理由。如果你的领导连钱都不care……

现状是：
很多CODER在CODE的时候都没有考虑以后的BUG,REVIEW,维护的时间...
那么你又怎能奢望领导来了解这些呢。
领导一般要明确的是:哥们，你那东东什么时候能提交?
他想的钱应该是:赶快把这个项目上去,就能回款了。该死的维护,再说吧。没准到时候还能收点钱。

28 楼 qinysong 2006-09-21  

结队编程是XP极限编成的一个关键实践，如果把结队编程放到整个XP里面会更容易体现出它的价值，所以我觉得分析结队编程的一个整体思路是：

1、适用场景：
XP的适用性在哪里，什么样的项目中适合采用XP，在这样的项目中XP可以起到什么作用。如果离开了适用场景，XP的适用性都要重新考虑，所以就更不用谈结队编程了；

2、实施条件：
从理论上我们面对的项目可以从XP那里得到很大的价值，但实际中我们的团队具不具备实施XP的条件，即并不是什么样的团队都可以采用XP，特别是结队编程；

3、结队编程的位置和价值：
结队编程在整个XP中的地位，它和其他哪些关键实践有着相辅相成的关系，它可以应对项目实施的哪些问题；

4、结队编程遇到的问题：
结队编程在实施的过程中，会遇到这样那样的阻碍和问题，这些阻碍和问题，可能是因为不恰当的使用引起，可能是因为对XP关键实践的局部采用引起，或其他。

1、适合场景：
适合采用XP的项目特征为：规模小，时间紧，需求变化多，质量要求高
而且我觉得这些特征不是“或”的关系，而是“并”的关系。
如果只是规模小、时间紧，但是需求变化不大，那么敏捷所强调的“拥抱变化”就谈不上了；
如果只是需求变化多，但是时间比较充足，那么可以侧重原形驱动方法；
如果规模比较大，需要几十个/上百个人、半年甚至一两年的项目，那么采用稍微重量级的RUP，还是要稳妥些。

所以如果我们怀疑XP以及结队编程的价值或者实施性的时候，可以考虑考虑我们面对的项目，是不是适合采用XP来开发，在这里我觉得应该强调的特征是需求变化多。

2、实施条件：
在实施条件上，我觉得团队需要具有XP的文化是很重要的，团队成员需要达成一个共识，就是认同XP开发会给项目以及自己带来价值，这种共识需要若干个因素，如团队意思/共享意识等等。
此外XP对团队成员的技术水平要求也较高

如果团队不具有XP的思想意识，以及必要的技术水平的话，那么就更谈不到结队编程的效果了（当然部分水平相当的人还是可以在适当的情况下，采用局部结队编程）

3、结队编程的位置和价值
在XP中，一个关键的假设就是“只注重眼前需求的简单设计而通过重构来适应需求变化”的代价和成本小于“对系统进行充分详细的设计，但是随着需求的变化设计失效”的代价和成本。
所以结队编程的价值在于，我们无法在项目的初期进行一个详细的设计，即使完成一个设计，随着需求的变化，设计也是需要频繁的改动，因此与其我们花费大量的时间和精力来维护不稳定的设计文档的一致性，不如我们简化、延迟设计，用简单的实现来满足当前的需求，而依赖重构来适应需求的变化。
所以结队编程的价值在于：
1、使代码实现的无错误、且最简单；
2、更好的、更有效地使代码易于重构；
3、进行及时、有效的重构，避免单人开发的惰性而不愿重构。

如果我们觉得我们有很成熟的设计，很稳定的架构，可以说我们的系统不需要重构就可以满足所有需求，那么我觉得结队编程的价值就大幅度下降了；
如果我们觉得我们的需求会不断变化，我们的设计需要不断的进行调整重构，那么结队编程是这种重构最好的保障和实施。

4、结队编程遇到的问题：
结队编程会带来效率的降低
在一个具有实施XP能力的团队，出现这样的问题往往是
i、由于人员的变动，来了新成员
在这种情况下，前期确实会对其搭档产生一定的影响，但是磨刀不误砍柴工，通过结队编程，可以最快的使新成员进入状态，通过后期的高效完全可以弥补前期的消极影响；

ii、后面坐着的人跟不上写代码的人的思路，写代码的人要不断对其讲解
结队编程不仅仅只是一起写代码，在写代码之前也需要一起对需求进行探讨，一起讨论设计方案，达成共识之后才再一起写测试用例，一起编码，一起测试。
如果出现跟不上的情况，那么赶紧停下来，需要讨论的时候到了。

iii、由于每个人有不同的习惯风格，坐在后面的人不习惯写代码人的代码风格
这正是XP另一个关键实践的必要性：代码规范。在采用ＸＰ方法后，要求所有成员编写的代码都想出自于一个人之手写的，这样才能使代码本身就是设计，方便所有成员沟通维护。
通过代码规范之后，也才使ＸＰ强调的另一个关键实践“代码共同拥有”成为有效。

iv、结队搭档步调不一样，如一个人有事或打电话，或去洗手间，另一个同伴岂不空闲
如果一个人有事那么另一个人可以对设计与实现重新进行思考，思考仍然是软件开发中最重要的事情之一。
此外自己也休息一下，也不是一件很坏的事，呵呵。

结队编程很累
结队编程确实是强度非常大的一件事情，在结队的时候我们就不可能边写代码边带着耳机听音乐了，呵呵。
但是结队可以使两个人精神更加集中，可以扩展思路以创造更简单，更严谨，更便于修改重构的代码，所以这正应对了项目时间紧的要求。
因为ＸＰ是一件强度很大的过程，所以ＸＰ强调４０小时／周的另一实践

27 楼 partech 2006-09-21  

adamzhao 写道

partech 写道

问题在于领导通常不会有这样精明的想法，由于从来没有实践过pair，也就没有比较。
实际上，我认为pair要推广开来，还需要花大把的努力，不光是钱的问题。

领导认同pair是为了钱，不认同也是为了钱。 只不过到底怎么做才能省钱却不是每个领导都知道的。

这同IT业普遍的长期加班比较类似，大家都骂头头傻，难道不知道长期加班工作效率低？
但实际上，他们就是这么干的！“秀才遇见兵”，你咋跟他说道理？

26 楼 抛出异常的爱 2006-09-21  

引用

当然，再有，找自己的原因。我是个不爱沟通的人，我很固执，我技术也不行，这样的后果是，别人看我很不爽。最后,他辞职了...

他辞职也好减少了老板炒你概率
技术不行。。。。固执。。。。不爱沟通。。。。听着怎么那么像老板的小舅子？

引用

领导认同pair是为了钱，不认同也是为了钱。 只不过到底怎么做才能省钱却不是每个领导都知道的。

大钱与小钱，看的见的钱与看不见的钱，认为最大的问题存在于眼光与现阶段的主要需求是什么。。。。

大家都知道星际移民是正路。。。。
但是谁会为星际移民出钱呢

25 楼 adamzhao 2006-09-21  

partech 写道

问题在于领导通常不会有这样精明的想法，由于从来没有实践过pair，也就没有比较。
实际上，我认为pair要推广开来，还需要花大把的努力，不光是钱的问题。

领导认同pair是为了钱，不认同也是为了钱。 只不过到底怎么做才能省钱却不是每个领导都知道的。

24 楼 partech 2006-09-21  

gigix 写道

钱。
烂代码是要花时间来修的，bug是要花时间来抓的，code review是要花时间来做的，一个人独自干了一个月的活别人要花很长的时间才能弄明白，更何况说不定哪天这人就走了，花的时间就更多。时间都是要钱的。
这就是pair的理由。如果你的领导连钱都不care……

问题在于领导通常不会有这样精明的想法，由于领导从来没有实践过pair，也就没有了比较。
实际上，我认为pair要推广开来，还需要花大把的努力，不光是钱的问题。

23 楼 gigix 2006-09-21  

moxie 写道

number017 写道

领导看来，那两个家伙怎么一整天都在那边聊天啊。工作不饱和。 这时候，我们需要一个不错的领导,他还要懂得XP(注意：不是WINDOWS XP)。可是，领导是你决定的吗？不是，所以...

问题：领导是否支持沟通，是否认为沟通在软件开发中处于核心地位？
如果领导认为软件开发中，沟通不重要，那么......
如果领导认为沟通很重要，而且很鼓励团队去进行频繁沟通，那么问题就解决一半了。

钱。
烂代码是要花时间来修的，bug是要花时间来抓的，code review是要花时间来做的，一个人独自干了一个月的活别人要花很长的时间才能弄明白，更何况说不定哪天这人就走了，花的时间就更多。时间都是要钱的。
这就是pair的理由。如果你的领导连钱都不care……

22 楼 moxie 2006-09-21  

number017 写道

领导看来，那两个家伙怎么一整天都在那边聊天啊。工作不饱和。 这时候，我们需要一个不错的领导,他还要懂得XP(注意：不是WINDOWS XP)。可是，领导是你决定的吗？不是，所以...

问题：领导是否支持沟通，是否认为沟通在软件开发中处于核心地位？
如果领导认为软件开发中，沟通不重要，那么......
如果领导认为沟通很重要，而且很鼓励团队去进行频繁沟通，那么问题就解决一半了。

number017 写道

还有，假设我的同伴是个不想干活、又喜欢无端争吵的人（你应该会碰到这种人）。那么我可能整天干活都没心情,看到他就不爽，最后，我再也不想PAIR了，最后，我辞职了...

假设一个团队10个人，这样的同伴估计最多只会有2－3个吧，每天SWITCH Pairer，这样一周也就和他们结队一次，站在团队的角度，忍一下吧，兄弟。不过，我不喜欢忍，我会去沟通，在合适的时候让他意识到自己的问题，提醒他，告诉他这样做是不对的。

number017 写道

当然，再有，找自己的原因。我是个不爱沟通的人，我很固执，我技术也不行，这样的后果是，别人看我很不爽。最后,他辞职了...

还是上面的答案，这样的我在团队中不会有太多，否则大家早就完蛋了。这样的我是需要学习和教育的。因为我辞职的家伙，是在逃避问题。每一家公司，多少都有很多让你不爽的地方，你不能逃一辈子。

21 楼 number017 2006-09-20  

和美女PAIR?我想到后来的结果大概是你自己在PROGRAMMING,美女在旁边剪指甲了。

再说了，你也知道，我们这行的，美女多吗？还是醒醒吧^_^小心回到侏罗纪时代

回到正题。
对PAIR PROGRAMMING很是感兴趣。
按照我自己的现状，一天8个小时（加班的时候达到10多小时）里面最多有4个小时是出活的时间，效率最高。如果PAIR了，可能我一整天都在和我的同伴进行激烈的讨论。也就是说，我们两个有8小时的出活时间。这么简单的量化，说明效率上没了问题。
再想想，PAIR的时候，我可能一些BUG被我的同伴预见了，那么你应该知道，我可能省去了一天的找BUG、改BUG的时间，或者更多...
再再想想，可能我和我同伴的PAIR的过程中，讨论的结果是很有建设性的，而不会象自己思考的比较片面。

这么来说，PAIR非常棒！

好处真不少，缺点说说：

领导看来，那两个家伙怎么一整天都在那边聊天啊。工作不饱和。 这时候，我们需要一个不错的领导,他还要懂得XP(注意：不是WINDOWS XP)。可是，领导是你决定的吗？不是，所以...

还有，假设我的同伴是个不想干活、又喜欢无端争吵的人（你应该会碰到这种人）。那么我可能整天干活都没心情,看到他就不爽，最后，我再也不想PAIR了，最后，我辞职了...

当然，再有，找自己的原因。我是个不爱沟通的人，我很固执，我技术也不行，这样的后果是，别人看我很不爽。最后,他辞职了...

20 楼 partech 2006-09-20  

结对编程能够增进团队成员的友谊，这是真的。
有些程序员不适应，往往和性格有关。

结对的方式，可以多种多样，这要看面对的任务类型。

和女程序员pair，确实不错，因为大量无意义的争论要少得多。男人是泥阿，男人加男人就是和稀泥，赫赫。

19 楼 抛出异常的爱 2006-09-20  

三个人时可以达成共识的可能性比四个人高一个数量级以此类推
五个人达成共识后产叛徒可能性比四个人高一个数量级以此类推

18 楼 riss 2006-09-20  

gigix 写道

这就是需要pair的理由之一：两个脑袋总好过一个。

依次类推,三个好过两个,四个好过三个.......岂不是越多越好了?(钻牛角尖了,SORRY!)

17 楼 gigix 2006-09-20  

抛出异常的爱 写道

不知道对
大多数的重覆工作
结对的好处在哪里？
如果是有必要思考的问题
很多人会有结对倾向
如果是由习惯可以完成的工作（如写Action时）
结对时习惯不一样
会产生很大的阻力。。。。
以前完成过但是现在要重完成的工作
会让士气下降的很快。。。。
PS：
对于结对来说，
是不是要减少重覆工作呢？
但是大量的学习新技术
与发明通用类的产生浪费
又很严重
不如重覆开发的生产力高

你怎么知道？
你怎么知道这次的重复是合理的，那次的重复是应该被重构的？
这就是需要pair的理由之一：两个脑袋总好过一个。

16 楼 抛出异常的爱 2006-09-20  

不知道对
大多数的重覆工作
结对的好处在哪里？
如果是有必要思考的问题
很多人会有结对倾向
如果是由习惯可以完成的工作（如写Action时）
结对时习惯不一样
会产生很大的阻力。。。。
以前完成过但是现在要重完成的工作
会让士气下降的很快。。。。
PS：
对于结对来说，
是不是要减少重覆工作呢？
但是大量的学习新技术
与发明通用类的产生浪费
又很严重
不如重覆开发的生产力高