困惑的结对编程？

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

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

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

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

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

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

       3、同时理解一个问题。

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

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

       代续......

评论

30 楼 dearwolf 2007-03-18  

每个人的阅读速度和理解能力也有偏差啊，我觉得这样子peer的效果肯定不好

29 楼 hyysguyang 2007-03-17  

呵呵，XP里面也提到，我们要有信心和勇气，要信任别人，信任你的同伴，你的搭档.PP也是一样，peer google吧，呵呵，可以一起看的啊。

28 楼 dearwolf 2007-03-17  

一台电脑，每个人想看的东西肯定不同

27 楼 basicbest 2007-03-17  

peer google :-,

26 楼 dearwolf 2007-03-17  

但是，当一种技术，或者理念，大家都不熟悉的时候，每个人都需要查很多资料，都需要google，这种情况下如何peer？

25 楼 hzhui 2007-03-17  

2006年的12月至今，我在一间对于国内来说应该算是很大的软件公司里面实习（因为这间软件公司的开发人员将近600人）。在进到这间软件公司之初，我们并没有马上接手实际的生产项目工作，而是首先进行为期二个星期的基础的不能再基础的培训（每个公司有每个公司的选人准则）。在培训完之后，我们进入了实战能力的考核阶段。公司把我们这批实习生分成了几个小组，每个小组四到五个人，然后分别用SSH（Struts+Spring+Hibernate，SSH）实现一个论坛。在我所分到的那个小组里面，因为每个组员的能力都不相同，所以我们组在开发的过程中，当有一个组员解决不了一个问题的时候，通常他都会交给另外一个比较能力更强的组员去解决，而接手这个问题的组员则把他正在做的任务交给他。于是，在我们组里经常会出现交换开发任务的现象，而且所有的问题都被解决，不但如此，我们组的所有组员对这个论坛的每一个模块都显得非常熟悉，因为每个人都经历过每一个模块。
与结对编程类似，交换编程也是一个非常简单和直观的概念：两位或者多位程序员轮流开发同一个软件系统的同一个模块的不同阶段的任务。交换编程的方式更合适的说法应该是交换开发，这种方式不仅仅可以应用于软件项目，也适合其他研究开发型项目。

24 楼 basicbest 2007-03-17  

PP应该更加适合研发型的项目。对于普通的开发项目，一般并不是非常合适。

23 楼 hzhui 2007-03-17  

dearwolf写道：
<table width="100%" bgcolor="red">
<tr>
<td>如果是研发性质的项目，结对编程就不适用了吧？</td>
</tr>
</table>

首先要说明，“结对编程”技术中的“编程”可以是软件开发过程中的任何一个阶段（设计、调试、测试，等等），而不是仅限于编写程序代码。也就是说，结对编程技术覆盖了结对设计、结对调试、结对测试等等各方面。事实上，结对还可以用于处理研发性质的项目，当你表示怀疑的时候，你可找找这方面的资料：
Auer,K.and Miller,R.(2002).Extreme Programming Applied;Playing to Win,Addison-Wesley.

22 楼 dearwolf 2007-03-17  

是的，我们应该是快乐的。

21 楼 hyysguyang 2007-03-17  

实际上，在我看来，只要能够帮助尽快的发现bug的，不管是什么方式，PP也好，还是其他的也罢，都已经大大的功臣的了，当然，应该还有其他的一些因素要考虑。我实在不愿意debug，因为debug太浪费时间了，何况即便你debug了，你也不一定能找出bug的所在。
     我还记得以前的很多时候，每次花了很久很久的时间debug的，到后面还是没有结果，问问旁边的同事，一起看看，OK，解决的爆快，然后就是大叫一句：郁闷，原来这样，然后同事笑笑：呵呵，当局者迷，旁观者清啊.
    我现在debug的时间已经比以前少了很多，因为我写测试，遗憾的是，还是看到很多兄弟整天在debug，我还是经常看到很多IDE（我们公司采用IDEA）上那个调试的蓝色背景在不端的往下滚......，我虽然喜欢蓝色，但是写代码的时候我还是更喜欢绿色，酷爱绿色条。  
    但从PP能够帮助我们降低bug数量上来说，我认为就已经很值得去实施它了。
     说实在的，我还是喜欢PP的，我就两次经历（实际上还算不上PP），但已经有了很多好处了，我更喜欢和MM一起PP......


引用daquan198163老兄的话：
我始终坚信，软件开发是一项伟大的、创造性的劳动，它应该是一件充满乐趣的事，同时给我们带来成就感和体面的收入；

程序员应该是一群快乐的家伙，每天享受着自己喜欢的工作，有足够的时间去打篮球、跟哥们儿喝啤酒、陪女朋友看电影；

20 楼 hyysguyang 2007-03-16  

hail 写道

结对编程我觉得在两个水平相当或者在意识、能力上互补的两个人身上应用时，效果会很不错！古语云“以人为镜，可以知得失”，结对编程就可以很好地形成一种互助共进的气氛和效用！

我也这么认为，但是即便两个人的水平不一样，也很又好处：知识传递，这是我亲身体会的，尤其是在培养新员工的时候。
嘿嘿.......
只可惜能结对的机会没有你想象的那么多，所以嘛，就要把握好机会罗，当然，如果所有的东西由你掌控，或者你的老大接受你的建议，那你的机会当然多多的了啊

19 楼 run_xiao 2007-03-16  

三人行，必有我师

我们的老祖宗早就教导我们要这样做了，呵呵

18 楼 basicbest 2007-03-14  

ans to:hzhui
您的数据我没有明白什么意思
“如果有一个需要一个人8小时开发的模块，将由8个人花一小时去写代码，也就是等于总共要花费16个工作人日”
这个“一个需要一个人8小时开发的模块”工作量不是8人时吗？为什么花费需要16人日？

抛开这个不谈，我理解您想要说明的意思。
但是，有一点，您举的例子是单纯的编码阶段的，如果以后软件开发不需要编码呢？这些所谓的数据还有没有意义？所以说这个是历史的产物。PP是peer review的一个具体实现，所以只能使用在特定的环境，特定的历史时间框架下。
还有一点是“协作”，如果为了PP而把两个人放在那里，表面上看起来在一起工作，结果一个人在写代码，另外一个人在睡觉。或者说两个人其实在聊天，这个都没有什么意义了。所以，PP比较理想化，可以认为是Y理论的体现，属于一种极端。

to:gigix
您给的数据是比较正确的，但是想稍微改一下：到“编码阶段”发现并修复的成本就为10
这个改为：到“实现阶段”发现并修复的成本就为1。
因为“编码阶段”是“实现阶段”的一种“实现”。
“由于频繁的peer review，设计、编码阶段的大量bug不会流转到测试、维护阶段。”
我个人认为对XP进行说明的例子都是很典型的，但是对一般的开发项目而言发生的概率并不大。比如某些算法的错误，某些字符的错误。但是对于研发型的项目可能作用更大些。
相对PP所能带来的好处，我更愿意把这些人力放在架构的设计及管理，以及迭代周期的缩短上。

顺便我们再来看一下XP里面的一个有趣的东西。XP建议团队规模不要大于12个，以及采用PP，这样Team Leader需要的管理能力在绝大多数时间其实是6。

17 楼 hail 2007-03-14  

结对编程我觉得在两个水平相当或者在意识、能力上互补的两个人身上应用时，效果会很不错！古语云“以人为镜，可以知得失”，结对编程就可以很好地形成一种互助共进的气氛和效用！

16 楼 lkfnn 2007-03-14  

我们的项目现在快交付了,有一些隐藏很深的bug,结队改bug真的效率很高.

15 楼 dongbin 2007-03-14  

dada 写道

dearwolf 写道

可以先把应用场景讲一下啊

我想这里很多人在结对编程这方面都会有很多疑惑吧

我上头的回复说了，以数据驱动为主的项目(在短期内不会改变)，有些是遗留系统并且有相对稳定、统一的框架，并且开发人员很熟悉这套框架。

自己试一下就知道了，你会喜欢上结对编程的。

14 楼 dada 2007-03-13  

dearwolf 写道

可以先把应用场景讲一下啊

我想这里很多人在结对编程这方面都会有很多疑惑吧

我上头的回复说了，以数据驱动为主的项目(在短期内不会改变)，有些是遗留系统并且有相对稳定、统一的框架，并且开发人员很熟悉这套框架。

13 楼 dearwolf 2007-03-13  

dada 写道

gigix 写道

假设的数据是一个起点。你可以把真实数据填充进去，得出你自己的结论。如果你连定性的分析都没有做，又为什么不肯接受这些假设的数据呢？

你的数据大体上我还是接受的，因为我的项目给了我这样的体验，最多就是各个阶段的倍率有所不同而已。
对于没有尝试过结对编程的我，与其给我一通我没有体验过的数据(指使用结对编程后的数据)，不如告诉我，在我的特定应用场景中，他能在哪些方面提高生产力。不同应用场景的差异很大，我想初学者都希望能有更有针对性的解答。

可以先把应用场景讲一下啊

我想这里很多人在结对编程这方面都会有很多疑惑吧

12 楼 dada 2007-03-13  

gigix 写道

假设的数据是一个起点。你可以把真实数据填充进去，得出你自己的结论。如果你连定性的分析都没有做，又为什么不肯接受这些假设的数据呢？

你的数据大体上我还是接受的，因为我的项目给了我这样的体验，最多就是各个阶段的倍率有所不同而已。
对于没有尝试过结对编程的我，与其给我一通我没有体验过的数据(指使用结对编程后的数据)，不如告诉我，在我的特定应用场景中，他能在哪些方面提高生产力。不同应用场景的差异很大，我想初学者都希望能有更有针对性的解答。

11 楼 dearwolf 2007-03-13  

如果是研发性质的项目，结对编程就不适用了吧？