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

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

——Laurie Williams &Steve Hayes

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

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

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

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

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

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

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

评论

15 楼 moxie 2006-09-20  

Mayer 写道

很多时候一个人有思路时就写得行云流水，并不希望还要与旁边一个人作交流。但是在攻克一些难题或时间较紧又要快速解决问题时结对的功效绝对是大大的好，因为这时更需要发散性思维，两个人的思维面更广，更容易找到解决问题的方法。

从个人的角度来说，是这样。有的developer技术很棒，思维很敏捷，不需要同伴就可以写出质量非常高的代码。而且，在刚开始实施结对编程的时候，要照顾自己的同伴，也许个人的工作效率还有所下降。
但是，从公司和团队的角度来说，这是非常不利的。这样，公司的技术和业务只会掌握在一小部分这样技术明星手中，如果一旦有人员流动，公司就会受到严重损失。
结对编程是一种编程模式，他可以大大的提供代码质量，但不是一个人的代码质量，而是整个项目整个团队的代码质量。我们希望通过这种编程模式，把软件开发的技术、方法、业务在整个团队中传递开。让大家一起互相促进、互相学习，互相影响。达到由心知到身到的过程。

14 楼 Mayer 2006-09-19  

其实，结对并不适用在全部的编程场景下，很多时候一个人有思路时就写得行云流水，并不希望还要与旁边一个人作交流。但是在攻克一些难题或时间较紧又要快速解决问题时结对的功效绝对是大大的好，因为这时更需要发散性思维，两个人的思维面更广，更容易找到解决问题的方法。

13 楼 moxie 2006-09-19  

抛出异常的爱 写道

3和4我也没有好办法，这和个人的天性有关。

对这句话理解有误

关于天性，我想说的是：道理，几乎每个人都懂。要多锻炼身体，多睡觉，少熬夜，少抽烟少喝酒，但是知道并不是每个人都会去做。很多人也知道敏捷，知道他是非常优秀的软件开发，知道他可以打造更高质量的软件，知道他可以更好的释放软件价值。但是，由国内传统的软件开发向敏捷过渡，是需要一个改变的过程，市场竞争将是改变的直接动力。在这个过程，必须由“心知达到身知”。不同的软件公司，公司的不同阶段，不同的团队，不同的项目，开发方法都是不尽相同，但也不尽完全不同。

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

3和4我也没有好办法，这和个人的天性有关。

对这句话理解有误

11 楼 moxie 2006-09-19  

不，我列出来的四种类型都是可以很好进行结对的。而且，很多软件公司第四种developer偏多，是结对的主力人群。第五种，没有办法，只能放弃。

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

如果案楼上说的
那就不要推广XP了
因为可以结对的人太少了。。。
至少要聪明才行


我认为不必要水平相近
我的第一份工作
我的第一个组长说过
如果你写的程序
别人看不懂
那么一定是你写错了。。

我每每写程序都以他的话为座佑名
每个人写的代码必须要
有一定基础的人看的懂才算是好程序
（很多功能的程序反而不是好程序）

第二不要让人猜你的想法
每个人的想法会随时间变化而变化
变化很小时连自己也不能查绝
但是两个人一起工作时会让另外一个人很苦恼
因为你十分钟之前作的东西
与你现在作的东西跟本没有一点关联
所以一定要说出来
我现在要做什么。。。。
而这一点很难作到真的很难。。。
我试了N次失败的次数正在减少但还达到50%
而其它的人一上来不熟悉
想要沟通不一定会比我与我搭挡更好（一起工作一年有余平时还一起吃饭聊天）


第三两个人一起工作很累的
比想像的还累
很容易就放弃了
每次都是很累
想明天不结对自己写程序多好

结对时间很短
还没有很好的效果产生。。。
生产率没提高多少

9 楼 moxie 2006-09-19  

别跑题了，各位。
据说在JavaEye里，有人是通过结对编程(Pair Programming)找到老婆的，站出来给大家谈谈心得体会吧。关于和美女Pair的故事，另开贴，在海阔天空板块讨论。
小跑一下。

引用

1) 结队的伙伴是否需要水平相近的？

“水平相近”，其实这个不能只理解为技术水平。

我把在项目中遇到的developer分为四类。
1、优秀型的Developer。有丰富的工作经验，很好的解决问题能力，善于沟通，有幽默感，还有生活情调。这个不说了，他在任何地方都是受欢迎的。

2、巨大潜力的Developer。没有工作经验，理解能力不错，悟性比较高，人很勤快，爱问问题，脾气也好，懂得尊重其他同事。这类developer，我们也非常喜欢。我们遇到一个这样的应届毕业生，刚来的时候，只会一些基本的Java知识，他在团队中工作5个月，并已成为客户公司的主力developer了。

3、Trick型的Developer。也许没什么经验，但思维非常活跃，也许喜欢狡辩，也偶尔会指责别人，有点小懒惰，而且会自我感觉非常良好。与这样的develoer合作时候，问题争论会很多，但对问题的理解也会更加深刻。这样的devloper，需要教育提醒。告诉他我们是一个Team，多用“我们”这个词，你指责别人，别人也会以同样的方式对你。如果能改正这些缺点，他绝对是个好同志。

4、普通的Developer。要么是技术不错，但是理解能力很弱；要么是沟通、理解能力不错，但是工作态度不好，爱混日子。和这样的developer 一起Pair是要辛苦一些，需要一些技巧。能把你的技术方案，讲得通俗易懂，这也正说明你思考正确和深刻，我们在开发的时候，要善于分解问题，将一个复杂的问题分解，小步前进，这样开发才有一个非常好节奏。工作态度不好的，那就多问问题，逼他思考工作.

最后如果还有一类,那就是没有救的,公司不该招的

引用

2) 很多人存在对充分/频繁的交流存在抵触情绪。

如果是抵触,那只能沟通。如果在团队中能有一个敏捷教练，将会好很多。

引用

3) “你累了吗？ 我们休息一下吧“
4) “自信，乐观“

3和4我也没有好办法，这和个人的天性有关。

8 楼 hyysguyang 2006-09-19  

哈哈，太搞笑了。
pair非常好，我也渴望和美女结队，只可惜很少有那个机会，连测试代码都不写，更不用提pair了。
，真希望有一天能和美女结队编码啊

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

楼上在做梦吧。。。。。

她在背后唠叼。。。。汗

6 楼 nihongye 2006-09-19  

我也想有美女跟我pair，最好一个项目组里有几个美女，换来换去都是美女。
要是每个项目组里都有一半美女，那就好了，来个组内switch,组外switch,
一年下来365天有每天都能接触到不同的美女，多美的梦想阿,到那个时候，
程序员便会成为最受女生欢迎的职业了，形成良性循环后，就不怕没有美女跟我们pair了。

5 楼 Readonly 2006-09-19  

firebody 写道

顺便提一下，我很乐意和美女一起pair的。

4 楼 firebody 2006-09-19  

珂儿 写道

[quote="firebody]

3) “你累了吗？ 我们休息一下吧“
需要全身心地投入，design,code , communication.
如果其中的一方没有全身心投入，pair的结果将会适得其反。

pair还需要照顾两个人的情绪？


我觉得很需要，就像“踢猫”那样，情绪会影响人的。比如结对的一方，如果一方心情不好懒得说话，对于另一方提出的问题也是不热情的态度，或者一个人因为心不在焉而去注意了其它，结对的过程其实也就另一个人工作的过程，则也是很影响效率的。
呵呵，记得刚入行时，那时根本就没有“结对编程”的感觉，总喜欢在同事们旁边看他们写程序，讨论交流，N久之后才发现原来这有一个学名：叫做极限编程。
我觉得越是富有创造力的工作，极限编程的优势越明显，像GOOGLE之类的公司，可惜普通的软件公司很少采取这样的做法的，因为头们总觉得成本过高。。。

顺便提一下，我很乐意和美女一起pair的。

3 楼 珂儿 2006-09-19  

[quote="firebody]

3) “你累了吗？ 我们休息一下吧“
需要全身心地投入，design,code , communication.
如果其中的一方没有全身心投入，pair的结果将会适得其反。

pair还需要照顾两个人的情绪？


我觉得很需要，就像“踢猫”那样，情绪会影响人的。比如结对的一方，如果一方心情不好懒得说话，对于另一方提出的问题也是不热情的态度，或者一个人因为心不在焉而去注意了其它，结对的过程其实也就另一个人工作的过程，则也是很影响效率的。
呵呵，记得刚入行时，那时根本就没有“结对编程”的感觉，总喜欢在同事们旁边看他们写程序，讨论交流，N久之后才发现原来这有一个学名：叫做极限编程。
我觉得越是富有创造力的工作，极限编程的优势越明显，像GOOGLE之类的公司，可惜普通的软件公司很少采取这样的做法的，因为头们总觉得成本过高。。。

2 楼 firebody 2006-09-19  

moxie 写道

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

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

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

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

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

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

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

非常乐意参加这样的讨论。
我从我的个人经验来提出几个看法：

1) 结队的伙伴是否需要水平相近的？
我的看法是虽然不必须需要，
但是我自己是希望能够得到水平差不多的合作伙伴，或者至少对代码有“感觉“的人。
因为我觉得这样才会成为互补的合作模式。否则，水平高的一方总归需要付出更多的努力，包括在交流，code。。。

2) 很多人存在对充分/频繁的交流存在抵触情绪。
两个人一起编码，就需要更多的交流，可能你讲一次，两次甚至更多，
合作伙伴也没有完全理解你的思路。这个时候，你是否会觉得“交流起来“
感觉比较累。很多人也是对此敷衍了事，“嗯，我懂了“ 这种话可以很轻易的
说出口，其实自己心里未必了解对方真正的意思，不了解合作伙伴的思路，
何以能够更“互补“的合作？
确实，交流需要成本。
一个design ,code，现在两个人一起，你还要付起把你的“desing ,code"给另外一个人看明白的
的义务。这个义务可以带来很多意想不到的好处。

比如，一个比较复杂的设计思路在你脑子构思了，然后你把它表达出来给合作伙伴听，
在你表达的过程中，越复杂的越难以让对方听明白的设计，越有可能存在问题。

如果不认识交流的重要性，那么pair也无从谈起。
但是，这个成本阻碍了很多人。


3) “你累了吗？ 我们休息一下吧“
需要全身心地投入，design,code , communication.
如果其中的一方没有全身心投入，pair的结果将会适得其反。

pair还需要照顾两个人的情绪？

4) “自信，乐观“
你的情绪和工作状态 影响着另外一个人的情绪和工作状态。

因为有这个问题，总是会存在一些不愉快地小插曲。

1 楼 moxie 2006-09-19  

资源：
1、http://www.pairprogramming.com这是一个专门介绍和研究Pair的一个网站。
2、《Pair Programming (结对编程)》这是我发表于《程序员杂志》第九期的文章。
3、本论坛曾经对结队编程的讨论帖《主题:  对于结对编程我有疑问》