代码改变世界

【转】结对编程及其优势

2010-11-12 23:12  flyingfish  阅读(642)  评论(0编辑  收藏  举报

http://baike.baidu.com/view/1149561.htm

简介

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

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

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

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

3、同时理解一个问题。

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

两个程序员具有相同的缺点和盲点的可能性很小,所以我们当我们采用结对编程的时候会获得一个强大的解决方案。而这个解决方案恰恰是其它软件工程方法学中所没有的。

在我们平时的编程当中,如果遇到一个非常难解决的问题(困难到对该项目产生厌烦的态度),那么你势必会希望录求帮助,无论是从信息量庞大的Internet网络里,还是从身边的技术大师里,你都会拼了老命去解决(前提是你有对计算机知识的势爱)。这个时候不妨采用结对编程试一下,其它的不说,可能感觉就不同。

 

结对编程的优势

其实结对编程坐起来很简单也很有趣,找个水平差的不太远的程序员和自己配成一对。只用一台计算机,大家选一个人坐在键盘前面负责输入,另一个人坐在后面口述。两个人要不断的交流,频率不应低于一分钟一次。整个的设计思想由后面只动口不动手的人主导,而由操键盘的人做实现。由于人的思维速度是快于输入代码的速度的。那么观看的人可以有空闲的时间做额外的思考,观察代码写的有没有问题,结构有没有问题。

如果程序员的经验积累足够,是很容易看出存在潜在问题的代码的,即表面上实现了功能,但实际上是一种糟糕的做法。这在XP中被称为代码坏味道,在 Martin Fowler的《重构》一书中有详细的介绍。两个有经验的程序员同时在一起工作,看起来好像浪费了一个人的时间:但实际上的效果确实完成了更高质量的代码。程序编的不那么容易出BUG,而且代码页写得更为优雅和紧凑.

关于结对编程,发现了一些新的受益之处。首先,它可以促进参与项目的程序员自身的提高,一对程序员工作的时候,水平较低的一方会潜移默化地受水平略高的程序员影响,学到一些新的东西。而水平高的一方同样因为不断地把自己的想法说出来而整理了自己的思路。

其次,一定时间周期地打乱配对,让参与项目的人员相互转换位置,使得维护繁杂的文档变得不那么重要。大家分组打乱后,口头的交流很容易让所有人都熟悉每个模块,这样对于公司也很有好处,项目中万一有人离开,也不至于影响到整个项目。最后,开发过程变得更为有趣,任何人的交流变得很多,大家关系更为融洽。

另外想补充一点的是,讲解XP的书籍上都没有提到,但是实际上却存在的一点:结对编程使得程序员被迫提高了工作效率。如果单独工作,在遇到困难的时候,并不是所有人都立刻积极地去解决问题,这时或许会上网和网友聊聊天,看看无关的网站等等。有可能因为工作的打断,大半天的时间都浪费了。看起来,程序员每天都在加班,实际有效工作时间往往还打不到6个小时。而结对编程有一种相互督促的作用,在一边工作疲惫状态不好使,另一边会起一个鼓励和激发斗志的作用。

而且两个人共用一台电脑,略带私人性质的聊天活动都会很自觉地不去进行了。结果一天下来,新实验结对编程的程序员都会喊累,神经紧绷8个小时的工作不累才怪。

从这个角度看,严格限制结对编程的程序员不准加班是合理的,实际上,开始每天甚至不必限制8小时工作,每天这样工作6小时队项目同样是非常高效的。

当两个人不断的互换角色,以至于最后谁也记不清哪行代码是谁敲的;团队内循环的分组以至于分不清到底那个模块该谁负责;反而大家的感觉会不错。整个项目的代码是团队共有,而不再是个人作品了。

 

其他资源:

http://henrychen2002.blog.163.com/blog/static/12910136200821131357779/

http://blog.csdn.net/qinysong/archive/2006/09/21/1262299.aspx

http://wenku.baidu.com/view/813057db6f1aff00bed51e27.html#

http://developer.51cto.com/art/201001/180642.htm