困惑的结对编程？

        在软件工程方法学中的XP方法中，最让人感到困惑是在实际XP实践中实施得最少的那一条原则，即是结对编程。

        很多人都有一种这么理解想法：XP的十二条原则中，其它的我都赞同，但是为什么要让两个人在同一台机器上编码？一个键盘两个人抢着打？空着别的机器干吗？

        结对编程技术是一个非常简单和直观的概念：两位程序员肩并肩地坐在同一台电脑前合作完成同一个设计。同一个算法、同一段代码或同一组测试、与两位程序员各自独立工作相比．结对编程往往只需花费大约一半的时间就能编写出质量更高的代码， 但是，人与人之间的合作不是一件简单的事情——尤其当人们都早己习惯了独自工作的时候、实施结对编程技术将给软件项目的开发工作带来好处．只是这些好处必须经过缜密的思考和计划才能真正体现出来。而另一方面，两个有经验的人可能会发现配对编程里没有什么技能的转移，但是让他们在不同的抽象层次解决同一个问题会让他们更快地找到解决方案，而且错误更少。

       结对编程还有其他多种好处：

       1、直接的、连续的代码回顾。

       2、与别人工作会增加责任和纪律性。

       3、同时理解一个问题。

       4、在有人盯着的时候去偷懒要困难得多！

        两个程序员具有相同的缺点和盲点的可能性很小，所以我们当我们采用结对编程的时候会获得一个强大的解决方案。而这个解决方案恰恰是其它软件工程方法学中所没有的。 
        在我们平时的编程当中，如果遇到一个非常难解决的问题(困难到对该项目产生厌烦的态度)，那么你势必会希望录求帮助，无论是从信息量庞大的Internet网络里，还是从身边的技术大师里，你都会拼了老命去解决(前提是你有对计算机知识的势爱)。这个时候不妨采用结对编程试一下，其它的不说，可能感觉就不同。

       代续......

评论

50 楼 hzhui 2007-03-28  

<p align='center'><font size='4' color='#800000' style='background-color: #c0c0c0;'><strong><u>再谈结对编程的障碍-----沟通</u></strong></font></p>
<p>  </p>
<p class='MsoNormal' style='text-indent: 21pt; line-height: 125%;'><span style=''>沟通问题是一个项目成功最重要的因素之一。一个项目可能并没有什么正式的软件过程，但是只要团队成员能够进行有效的沟通，项目成功的可能性就很大，但是如果项目中缺乏有效的沟通渠道，再优秀与严谨的软件过程也没有用。优秀的软件方法学，总是会在沟通渠道的建立，推动在有效沟通上花费大量的精力，将会使项目获得更大的成功。我们分析</span><span lang='EN-US'>RUP</span><span style=''>、</span><span lang='EN-US'>XP</span><span style=''>等方法学，都会看到很多这样的实践。沟通对一个项目而言是重要的，对一个软件组织而言就更重要了。从长期来看，内部能够进行有效沟通的组织能够得到很好的发展，但是反过来，内部沟通不畅的组织将会出现很多的问题。</span></p>
<p class='MsoNormal' style='text-indent: 21pt; line-height: 125%;'><span style=''>  </span></p>
<p class='MsoNormal' style='text-indent: 21pt; line-height: 125%;'><span style=''>在软件开发过程存在的一个很大的问题就是沟通不畅的问题。事实上，这个问题并不仅仅在一个开发过程中存在，在整个软件组织内都将长期的存在，并成为阻碍软件组织发展的一大障碍。这样的说法可能过于理论化，但是我们只要想想，如果在的项目中，一个主力程序员离开的话，是否会给项目，甚至组织带来重大的影响，就能够理解这段话的含义了。造成这种现象的主要问题是程序是分散在各个程序员手中的，各个代码块就像是程序员们的私有财产一样，神圣不可侵犯。</span></p>
<p class='MsoNormal' style='text-indent: 21pt; line-height: 125%;'><span style=''/></p>
<p class='MsoNormal' style='text-indent: 21pt; line-height: 125%;'><span lang='EN-US' style=''>&lt;o:p&gt;待续.........&lt;/o:p&gt;</span></p>
<span lang='EN-US' style=''>&lt;o:p&gt;
<p class='MsoNormal' style='text-indent: 21pt; line-height: 125%;'/><hr/>
<p/>
<p class='MsoNormal' style='text-indent: 21pt; line-height: 125%;'>Blog:http://huangzh.iteye.com</p>
<p class='MsoNormal' style='text-indent: 21pt; line-height: 125%;'>E-Mail:[e-mail],[e-mail]</p>
&lt;/o:p&gt;</span>

49 楼 hzhui 2007-03-24  

很多软件公司都拥有自己的知识库，有的还有自己的专门培训部门，有的甚至还花大价钱来聘请一些专家做技术培训（就像我去年12月份底到eshore里实习所见的一样）。但是它们在不久的将来会发现其效果并不是太理想，培训完之后，开发人员就要面临实际的项目，但他们还会是一片茫然。如果让他们与有经验的同事一起结对的话，则是在实际的项目中学习，而且具有非常强的针对性。你学到的不仅是一些技术和技巧，更多是他们思考问题方式、解决问题的方法。和各种不同经验的同事一起结对，你的经验和能力将可以得到空前快速的提高。

48 楼 hzhui 2007-03-24  

看到这么多人对此贴这么感兴趣，那么就让它接着下去吧。你也可以到此http://huangzh.iteye.com来阅读或发表更多有关敏捷开发（结对编程）技术。



如果你不是一位经理，但是根据你自己的所见所闻，却又想在你们的公司试试结对编程技术，你应该怎么办呢？这里建议你充当一名传教士，在你的同事中先对一种偶然地且不经意的实践来开始你的传教。做为一门职业，程序员的工作负担是相当重的--------你本人可能也是如此。要想说服同事们广泛接受一种新事物，你首先要有一个坚定的信念，因为你肯定不想因此而增加自己的工作负担，也肯定不希望为了这种“业余活动”而让自己加班加点。因此，建议你先替自己准备一个风险转移策略。从小处入手，在试图说服别人之前先要说服自己。
你得先从自己的团队里找出几个看起来对新事物特别感兴趣的人，把这些人当作候的尝试者,因为这些人是不会容忍那些半生不熟悉的东西。首先，你可以试首在午餐或工休的时间与这些人非正式地讨论一下结对编程技术。不过你一定要有的放矢地准备一份个人接触方案，一份专为某个候选尝试者而准备的关于结对编程技术将如何在工作上给他们带来好处。因为尝试者衡量这些好处的标准之一就是该项创新能给他节省多少时间和精力。

47 楼 hzhui 2007-03-24  

江南白衣 写道

   我们最近的工作方式是半天自由活动，半天4个人在可以无线上网的小会议室，4个本本1个投影仪搞4P，比PP更爽更YL的说。

   在实践过的2P中，Peer Design 和Peer Debug 这两种PD地球人都知道是可行的，还有一种设计师偷懒，动口不动手，一边看一边带Coder的Peer Program效果也不错。可惜水平完全相同的两个程序员2P这种真正的PP在公司还没条件试验。

其实，有时候水平相同的两个程序员的确很难找到，但作为一间大公司，如果你真想要这样的程序员出现的话，我相信你会找到的，即使真的在市面上找不到的话，你也是可以自己花一点代价培养出一两队这样的程序员。如果真能培养出这样的程序员，相比你花的这一点代价来说，他们所能给公司带来的价值是巨大的。

46 楼 basicbest 2007-03-24  

看来javaeye的评级制度真是恐怖，特别是隐藏这条。上面的那个又来个几个评一分的。
前几天看了《Getting out of the box》.文人相轻的根源是都憋在自己做的盒子里。
老子说了一些“逆人道”的话，我渐渐明白了他的道理。

45 楼 somebody 2007-03-22  

hyysguyang 写道

实际上，在我看来，只要能够帮助尽快的发现bug的，不管是什么方式，PP也好，还是其他的也罢，都已经大大的功臣的了，当然，应该还有其他的一些因素要考虑。我实在不愿意debug，因为debug太浪费时间了，何况即便你debug了，你也不一定能找出bug的所在。
     我还记得以前的很多时候，每次花了很久很久的时间debug的，到后面还是没有结果，问问旁边的同事，一起看看，OK，解决的爆快，然后就是大叫一句：郁闷，原来这样，然后同事笑笑：呵呵，当局者迷，旁观者清啊.

这一点我也很有体会。不过遇到问题我还是会现debug，不过debug确实比以前少了。因为有开始的单元测试。需要花太多时间的话，就想同事请教。经常碰到"旁观者清"的情况。

本身我还没有体验过pp编程。很希望有机会试试。

44 楼 gigix 2007-03-22  

basicbest 写道

how?
至少这个时候PP是不合适的，但是可以用指导的方式。注意这个和PP是有很大区别的，PP是平等，而这个时候需要划出一定的层级来适应人性，使得这两位仁兄能够一起工作。

pair programming有很多种不同的风格，其中至少有一种是专门供资深开发者辅导新手的。
所谓指导，如果你不能立即、持续地看到效果，那么效果就会大打折扣。如果是要辅导新手，我更认为应该pair，采用“ball and wall”风格。

43 楼 giscat 2007-03-22  

结对就免了，交换代码走查下就可以

42 楼 hgq0011 2007-03-22  

江南白衣 写道

   我们最近的工作方式是半天自由活动，半天4个人在可以无线上网的小会议室，4个本本1个投影仪搞4P，比PP更爽更YL的说。

   在实践过的2P中，Peer Design 和Peer Debug 这两种PD地球人都知道是可行的，还有一种设计师偷懒，动口不动手，一边看一边带Coder的Peer Program效果也不错。可惜水平完全相同的两个程序员2P这种真正的PP在公司还没条件试验。

我2P都没有试过，你们就开始4P了， 真是先进，爽！

41 楼 basicbest 2007-03-22  

江南白衣 写道

   我们最近的工作方式是半天自由活动，半天4个人在可以无线上网的小会议室，4个本本1个投影仪搞4P，比PP更爽更YL的说。

   在实践过的2P中，Peer Design 和Peer Debug 这两种PD地球人都知道是可行的，还有一种设计师偷懒，动口不动手，一边看一边带Coder的Peer Program效果也不错。可惜水平完全相同的两个程序员2P这种真正的PP在公司还没条件试验。

所以，就像这里展现的，根本的问题是合作，如果一个团队是相互合作的团队，根本就不需要固定的PP方式存在，这种合作会使得问题发生的时候自发产生一种组织形式来适应解决问题的方法。
PP是一个强制性的平等关系，和乌托邦没什么两样。都很美丽，在某些瞬间都会有实现了的场景，但是仅限于瞬间。

40 楼 basicbest 2007-03-22  

gigix 写道

hurricane1026 写道

gigix 写道

hurricane1026 写道

对于人才济济的公司，例如TW，MS,Google,IBM来说,进行结对很不错.因为人员素质高.但是有些小公司用结对还可以么?

depends
我仍然重复前面的话：如果你对于pair programming的concern是耗费时间，请考虑defects流入项目后期所带来的成本。

我的意思是说,人员参差不齐.2个水平差异很大的人结对,太痛苦了...见过那种痛苦.......
小公司该怎么办呢?如何用it民工干出相对过的去的产品呢?

otherwise how can they?
pair programming is not silver bullet. no silver bullet.

how?
至少这个时候PP是不合适的，但是可以用指导的方式。注意这个和PP是有很大区别的，PP是平等，而这个时候需要划出一定的层级来适应人性，使得这两位仁兄能够一起工作。

39 楼 foxty 2007-03-21  

我曾经在团队中尝试过peer。

我觉得，绝对首先要建立在大家互相信任的基础上才能进行。另外：我认为有几个地方比较适合peer：

1，老员工 + 新员工 ：这里的老和新并不一定是指各自的工作经验，而是相对我们团队来说，后来的就是新进员工。可能你进来前1，2个星期，我会让一个老员工和你一起工作，不仅仅是编程，还包括讨论，分析等等活动。好处很明显：
    a，可以让新员工很快熟悉我门的开发框架，开发流程以及项目中的大部分规范和要求，这个要比新原来去啃稳当扎实的多。
    b，更可以增进员工之间的默契，这样以后大家一起工作就会沟通的更加顺畅。
    c，以前我们是家创业型公司，主要做web2.0方面的东西。这样也更有利于思想的碰撞。

2，引入新技术（有一定技术风险的）：
   有时候，由于项目需要，可能会引入其他的技术，而这种技术是团队内部都不是太熟悉的。那么我会安排两个比较合适的成员一起来共同研究这个新的东西。这样不仅可以防止某一个人陷入思维的死角，也更有利于新技术的推广。

其实，这些东西，需要自己亲自体验过后，才能知道具体有没有效果，并不是拿一堆假设的数字来推测，计算就能得结果的。突然想到这么多，就写到这里吧。

38 楼 江南白衣 2007-03-21  

   我们最近的工作方式是半天自由活动，半天4个人在可以无线上网的小会议室，4个本本1个投影仪搞4P，比PP更爽更YL的说。

   在实践过的2P中，Peer Design 和Peer Debug 这两种PD地球人都知道是可行的，还有一种设计师偷懒，动口不动手，一边看一边带Coder的Peer Program效果也不错。可惜水平完全相同的两个程序员2P这种真正的PP在公司还没条件试验。

37 楼 ahuaxuan 2007-03-21  

basicbest 写道

PP确实需要有团队文化和人员素质作为前提条件。特别是现在国内依然浮躁的氛围。但是PP如果正确使用，确实可以带来品质的提升。
所以一味的说PP好或者不好都是不正确的。我们需要考虑该方法是不适合当前组织的状态。而且，PP的作业方式是在需要使用的时候用，而不是强制性一定要用。亦即不能为了PP而PP，否则便是本末倒置了。

非常有道理，让我想起了ejb开始时候的情况，就是滥用，不考虑实际环境的滥用导致了失败，我想pp也是一样，至少在中国更要谨慎，不开个贴讨论一下pp在什么情况下使用会比较成功。

36 楼 gigix 2007-03-21  

hurricane1026 写道

gigix 写道

hurricane1026 写道

对于人才济济的公司，例如TW，MS,Google,IBM来说,进行结对很不错.因为人员素质高.但是有些小公司用结对还可以么?

depends
我仍然重复前面的话：如果你对于pair programming的concern是耗费时间，请考虑defects流入项目后期所带来的成本。

我的意思是说,人员参差不齐.2个水平差异很大的人结对,太痛苦了...见过那种痛苦.......
小公司该怎么办呢?如何用it民工干出相对过的去的产品呢?

otherwise how can they?
pair programming is not silver bullet. no silver bullet.

35 楼 basicbest 2007-03-21  

PP确实需要有团队文化和人员素质作为前提条件。特别是现在国内依然浮躁的氛围。但是PP如果正确使用，确实可以带来品质的提升。
所以一味的说PP好或者不好都是不正确的。我们需要考虑该方法是不适合当前组织的状态。而且，PP的作业方式是在需要使用的时候用，而不是强制性一定要用。亦即不能为了PP而PP，否则便是本末倒置了。

34 楼 gigix 2007-03-20  

hurricane1026 写道

对于人才济济的公司，例如TW，MS,Google,IBM来说,进行结对很不错.因为人员素质高.但是有些小公司用结对还可以么?

depends
我仍然重复前面的话：如果你对于pair programming的concern是耗费时间，请考虑defects流入项目后期所带来的成本。

33 楼 gigix 2007-03-20  

gurudk 写道

两个平庸的人结对也不一定等于一个高手，感觉结对编程不是适用于所有团队。如果两个很有经验的开发人员结对，岂不是浪费时间。另外，开发的时候，理思路，思考算法都需要相对安静的空间。从文化上讲，东方人相对保守，也不太适应这种编程方式，希望有些真正实践过的说些优缺点，我们不能一味的觉得人家国外大师说的就是对的， 要有独立思考能力，关于敏捷宣言，我不太赞同他对文档的观点。

如果一定要上升到这个高度的话，在我看来（一部分）中国人最需要的是少点主意，少点推理，多点实践，多点学习。结对编程是不是有利，在什么情况下有利，不需要去推理去猜测，找一个称职的导师带着你做一段时间自有体会。ThoughtWorkers都算相当有经验的开发人员吧？我们仍然每天结对编程。
至于“浪费时间”一说，我在很前面的一个回帖就说了：仅仅是尽早发现defect带来的成本节约，就足以值回票价。
补充一句：两个平庸的人不管用任何方式也达不到一个高手的水准。尤其在软件开发这件事上面，高手和低手的效率差可以是十倍、百倍。你能做到的最好的事情，就是尽快发现谁是高手谁是低手，而不是让平庸的人每天缩在格子间里混日子。

32 楼 gurudk 2007-03-20  

两个平庸的人结对也不一定等于一个高手，感觉结对编程不是适用于所有团队。如果两个很有经验的开发人员结对，岂不是浪费时间。另外，开发的时候，理思路，思考算法都需要相对安静的空间。从文化上讲，东方人相对保守，也不太适应这种编程方式，希望有些真正实践过的说些优缺点，我们不能一味的觉得人家国外大师说的就是对的， 要有独立思考能力，关于敏捷宣言，我不太赞同他对文档的观点。

31 楼 hyysguyang 2007-03-18  

嗯，这个的确是个问题,peer的效果估计不是很好，这个没有经历过啊