困惑的结对编程？

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

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

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

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

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

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

       3、同时理解一个问题。

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

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

       代续......

评论

70 楼 lei_1021 2007-08-17  

结对编程是需要在具体的人和事上具体的分析的

69 楼 gigix 2007-08-16  

hover1215 写道

如果两个人开发能降低bug。

那么：

那五个人一块做一个模块，是不是根本就不会有bug了。

这样就不需要再测试了。人越多，bug越少。是吗？；）

永远都有人不明白为什么不吃饭会饿死吃太多会撑死

68 楼 hzhui 2007-08-16  

结对编程 != 五个人一块做一个模块

67 楼 hunk 2007-07-28  

那样沟通所带来的成本可能会远远超过修复bug的成本--边际效应

hover1215 写道

如果两个人开发能降低bug。

那么：

那五个人一块做一个模块，是不是根本就不会有bug了。

这样就不需要再测试了。人越多，bug越少。是吗？；）

66 楼 hover1215 2007-07-27  

如果两个人开发能降低bug。

那么：

那五个人一块做一个模块，是不是根本就不会有bug了。

这样就不需要再测试了。人越多，bug越少。是吗？；）

65 楼 hyhongyong 2007-07-27  

还没试过pp，不过感觉应该能降低bug率。
两个人一块做事，有相互间脑力激发的情况。

64 楼 movingboy 2007-07-26  

结对编程不是万灵药，前面有人说了，no silver bullet......

在团队中没有人真正理解它的时候强推PP，效果很可能是事倍功半
但PP值得尝试，当大多数队员能理解它的时候，在正确的时机应用它，或许它的威力才能真正显现出来......

63 楼 gigix 2007-07-26  

kabbesy 写道

结对编程也有个大麻烦：我的缺陷被同伴看到了怎么办

那你就可以及时改进

62 楼 kabbesy 2007-07-25  

结对编程也有个大麻烦：我的缺陷被同伴看到了怎么办

61 楼 bryanzk 2007-04-24  

如果一起pp的两个人彼此互相克隆的话，我想这个效果应该不如两个有差异的人来的好吧？多样性是幸福之源~~

60 楼 daquan198163 2007-04-18  

明显是test case呀

pp有一个很大的好处似乎没人提到——防止有人偷懒、炒股、泡mm

59 楼 抛出异常的爱 2007-04-17  

楼上。。你认为你的公司支付的起一群牛人的工资增长么？

emarket 写道

另外 PP 的另一个好处是TDD的时候两个人可以想出更多的case, 这也是为何可以减少defect的原因，也是我们PP的努力方向

但是这一点是有前提的，新手往往由于对问题的不熟悉而不能发现更多的case, 老手因为要照顾新手而不能想出比自己单干的多。所以新手和老手PP往往是会带来更多的defect。（除非新手的智商过人）

还有一点就是如果老手对domain很熟悉，而又接受过正规的 测试训练， 一个人是完全可以找到大部分case的，当然这和人有关。 PP也不能保证两个人找到的case一定就比一个人多。

你说的case
是指user case 么
在开发的过程中想可能的case么？
那么在开始设计时会减少很多劳动。。。
但文档的收集不是很费力么？

58 楼 dongbin 2007-04-17  

emarket 写道

还好我是个 XP developer, 不过我们这儿不流行工作证，否则可以扫描份法上来。

华人的自学性高是以群体而言，是和老美的群体比较而言，n年前我的同事都是华人，现在我的同事都是老美，孰优孰略我心里有数。

至于垃圾程序员，我还是建议他们转行吧，PP帮不上忙，这点我们达到了共识:)

不过事实却总是事与愿违，一个公司总会找些低手和高手，一部分低手通过自身（注意是自身）的修行可以成为高手，PP可以在此过程中起到“师傅领进门”的作用。 而大部分XP的鼓催者 就拿让高手和低手PP可以把低收变成高手同时又会事半功倍减少defect的神话来混淆视听，而忽略了“修行靠个人”这个重要的条件。 我当然同意和我的克隆pair的话，我们的defect会比我自己降低。但是真实的情况是很难找到门当户对的：（   。 但是如果是mentoring session, 我们的代码的defect会上升 （相对于我独立完成的），因为一方面我要顾及如何指导新人，一方面我要考虑如何设计系统。 但是不可否认的是，pp的代码的defect会相对于 新手独立完成的 defect 有所降低。 但是其中降低和提高多少都回有个度的问题。

我没有想要全盘否定PP， 因为我也是从低手过来的，当然知道“师傅”在其中的作用功不可没，但是没有我自我的修行，可能还是在原地踏步。 
所以我赞成，
1. 门当户对的PP可以事半功倍
2. 一般的公司10-30%的pair 可能是门当户对的PP. 这一点要看公司而定，thoughtworks可能会高些，因为你们的招聘过程比较XX，pay也比较XX, turn over也比较XX
3. 在项目时间允许的条件下, 可以允许mentoring session based PP, 但是PM必须理解到这个PP是赔本的。但是这种1:1的培训效果会比1:N的培训效果好些。 但是如果新手不自我修行，什么都是白搭。
4. 在项目紧的情况下，而组里又有比较多新手的条件下，集中培训+自学 的方法比PP要更节约成本。
5. 新手必须承担一部分压力去自我修行。否则没有一种办法可以凑效。

BTW: code review的工作PMD 的eclipse plugin 作的很不错。我们pair的时候code level的全部交给PMD的， 而我们着重于design level的 review.

另外defect的引入和复杂性是有关系的，微软那么多高手， 不是一样bug很多。 所以高手working on 复杂的，低手working on 简单的 比高手和低手pair on复杂的 引入更多defect（相对于高手独立）然后再pair on 简单的 减少defect (相对于低手独立)] 要好得多。 因为在复杂问题上引入defect往往比在简单问题上引入defect严重的多。

新手也要分学习能力强的新手和学习能力弱的新手，强的不用管他，自己会变成牛人；弱的赶紧开除，免得碍事。

57 楼 emarket 2007-04-17  

另外 PP 的另一个好处是TDD的时候两个人可以想出更多的case, 这也是为何可以减少defect的原因，也是我们PP的努力方向

但是这一点是有前提的，新手往往由于对问题的不熟悉而不能发现更多的case, 老手因为要照顾新手而不能想出比自己单干的多。所以新手和老手PP往往是会带来更多的defect。（除非新手的智商过人）

还有一点就是如果老手对domain很熟悉，而又接受过正规的 测试训练， 一个人是完全可以找到大部分case的，当然这和人有关。 PP也不能保证两个人找到的case一定就比一个人多。

56 楼 emarket 2007-04-16  

抛出异常的爱 写道

下三滥的公司就应该被淘汰。。。
因为他们自己都不知道自己作了什么

很遗憾，这需要一个过程。 而且通常这种公司能够讨得用户的欢心，因为通常用户也不知道他们要什么：）

55 楼 emarket 2007-04-16  

gigix 写道

emarket 写道

一个高级的dev和一个新手之间的pair永远是浪费project的时间。对于公司来讲可能或者大概能够节约培训成本。 但是对于自学性极高的华人来说似乎这种所谓的pair帮助不大。

那么，为什么自学性极高的华人中还有那么多垃圾程序员呢？照我的观察，尽管自学性极高，华人垃圾程序员的比例似乎也并没有比洋人要来得低。这能为你的“培训成本无用论”做一个注脚吗？

emarket 写道

另外所谓 pair　可以减少ｄｅｆｅｃｔ　也缺乏实际的统计数据。　ｄｅｆｅｃｔ多少跟人的关系很大。相信ｔｈｏｕｇｈｔｗｏｒｋｓ的ｐａｙ　应该不错吧。如果我开个下三滥的公司，ｐａｙ只有thoughworks的十分之一也照用ｐａｉｒ，defect应该不知会多10倍吧。

你真的是程序员吗？
第一，pair programming可以看作一种非常频繁的code review，所以不管你的人是水平高还是水平低，pair programming都有助于降低defect。我希望你能理解什么叫“降低”，那是在你原有的基础上降低。没有任何方法能把垃圾程序员一下子就变得优秀。
第二，pay只有ThoughtWorks十分之一的下三滥公司，造成的defect绝对是ThoughtWorks的一百倍以上。程序员的水平与收入成平方正比，我以为这早已是软件行业人所共知的事情。

还好我是个 XP developer, 不过我们这儿不流行工作证，否则可以扫描份法上来。

华人的自学性高是以群体而言，是和老美的群体比较而言，n年前我的同事都是华人，现在我的同事都是老美，孰优孰略我心里有数。

至于垃圾程序员，我还是建议他们转行吧，PP帮不上忙，这点我们达到了共识:)

不过事实却总是事与愿违，一个公司总会找些低手和高手，一部分低手通过自身（注意是自身）的修行可以成为高手，PP可以在此过程中起到“师傅领进门”的作用。 而大部分XP的鼓催者 就拿让高手和低手PP可以把低收变成高手同时又会事半功倍减少defect的神话来混淆视听，而忽略了“修行靠个人”这个重要的条件。 我当然同意和我的克隆pair的话，我们的defect会比我自己降低。但是真实的情况是很难找到门当户对的：（   。 但是如果是mentoring session, 我们的代码的defect会上升 （相对于我独立完成的），因为一方面我要顾及如何指导新人，一方面我要考虑如何设计系统。 但是不可否认的是，pp的代码的defect会相对于 新手独立完成的 defect 有所降低。 但是其中降低和提高多少都回有个度的问题。

我没有想要全盘否定PP， 因为我也是从低手过来的，当然知道“师傅”在其中的作用功不可没，但是没有我自我的修行，可能还是在原地踏步。 
所以我赞成，
1. 门当户对的PP可以事半功倍
2. 一般的公司10-30%的pair 可能是门当户对的PP. 这一点要看公司而定，thoughtworks可能会高些，因为你们的招聘过程比较XX，pay也比较XX, turn over也比较XX
3. 在项目时间允许的条件下, 可以允许mentoring session based PP, 但是PM必须理解到这个PP是赔本的。但是这种1:1的培训效果会比1:N的培训效果好些。 但是如果新手不自我修行，什么都是白搭。
4. 在项目紧的情况下，而组里又有比较多新手的条件下，集中培训+自学 的方法比PP要更节约成本。
5. 新手必须承担一部分压力去自我修行。否则没有一种办法可以凑效。

BTW: code review的工作PMD 的eclipse plugin 作的很不错。我们pair的时候code level的全部交给PMD的， 而我们着重于design level的 review.

另外defect的引入和复杂性是有关系的，微软那么多高手， 不是一样bug很多。 所以高手working on 复杂的，低手working on 简单的 比高手和低手pair on复杂的 引入更多defect（相对于高手独立）然后再pair on 简单的 减少defect (相对于低手独立)] 要好得多。 因为在复杂问题上引入defect往往比在简单问题上引入defect严重的多。

54 楼 抛出异常的爱 2007-04-15  

下三滥的公司就应该被淘汰。。。
因为他们自己都不知道自己作了什么

53 楼 gigix 2007-04-15  

emarket 写道

一个高级的dev和一个新手之间的pair永远是浪费project的时间。对于公司来讲可能或者大概能够节约培训成本。 但是对于自学性极高的华人来说似乎这种所谓的pair帮助不大。

那么，为什么自学性极高的华人中还有那么多垃圾程序员呢？照我的观察，尽管自学性极高，华人垃圾程序员的比例似乎也并没有比洋人要来得低。这能为你的“培训成本无用论”做一个注脚吗？

emarket 写道

另外所谓 pair　可以减少ｄｅｆｅｃｔ　也缺乏实际的统计数据。　ｄｅｆｅｃｔ多少跟人的关系很大。相信ｔｈｏｕｇｈｔｗｏｒｋｓ的ｐａｙ　应该不错吧。如果我开个下三滥的公司，ｐａｙ只有thoughworks的十分之一也照用ｐａｉｒ，defect应该不知会多10倍吧。

你真的是程序员吗？
第一，pair programming可以看作一种非常频繁的code review，所以不管你的人是水平高还是水平低，pair programming都有助于降低defect。我希望你能理解什么叫“降低”，那是在你原有的基础上降低。没有任何方法能把垃圾程序员一下子就变得优秀。
第二，pay只有ThoughtWorks十分之一的下三滥公司，造成的defect绝对是ThoughtWorks的一百倍以上。程序员的水平与收入成平方正比，我以为这早已是软件行业人所共知的事情。

52 楼 emarket 2007-04-15  

mentoring session 不是是pairing session. 更不是什么 一种pair 的风格。确切的来说应该是onsite training.

一个高级的dev和一个新手之间的pair永远是浪费project的时间。对于公司来讲可能或者大概能够节约培训成本。 但是对于自学性极高的华人来说似乎这种所谓的pair帮助不大。

另外所谓 pair　可以减少ｄｅｆｅｃｔ　也缺乏实际的统计数据。　ｄｅｆｅｃｔ多少跟人的关系很大。相信ｔｈｏｕｇｈｔｗｏｒｋｓ的ｐａｙ　应该不错吧。如果我开个下三滥的公司，ｐａｙ只有thoughworks的十
分之一也照用ｐａｉｒ，defect应该不知会多10倍吧。

我曾经面试过一个人，我们问他怎么可以减少defect. 期待的回答当然是pair TDD. 但是他的回答是：“to find the guy smart enough”.  软件的defect不可避免，process和人都可以减少defect的出现，相对来说人的因素更重要。

51 楼 longking 2007-03-30  

楼上的,转贴最好说明