没有合适的资源?快使用搜索试试~ 我知道了~
资源推荐
资源详情
资源评论
第一部分 结对编程技术理论
从表面上看,结对编程技术只是一个非常简单的概念:两名程序员使用同一台计算机去完成同一项任
务。
如果事情真的如此简单,我们也就用不着写这样一本书了。结对编程技术将涉及到各具特点得人,这
些人和这些人的特点已经因为常年的生活与工作而固定下来,让他们相信结对编程比独自工作更好并不是
件容易的事。软件开发团队的成员几乎都是些“独行侠”,让他们放弃长年养成的工作习惯而与其他人分享
荣誉是很困难的。每位项目经理的手下都有那么一两位与别人老死不相往来的程序员。那么,项目经理为
什么要把程序员结对组合在一起呢?要知道,团队文化是很难改变的。
我们将尝试回答:结对编程技术为什么能帮助你的团队取得最大成就并使之适应这种企业文化方面的
改变。
第 1 章 结对编程技术简介
程序员——前 Rice University(莱斯大学)、现 Northeastern University(东北大学)教授 Matthias Felleisen
是这样形容程序员的:“一群面对比特与字节之海却各自为战的骑士。”编程时快乐的,它集中体现了创造
性、复杂性和逻辑性。当获得成功时,我们会像孩子般为我们创造出来的事物以及它给生活带来的改善而
欢呼;当遭遇挫折时(事实也往往如此),我们又会恨不得把头撞在墙上。一个被漏掉或者打错的字符可能
要花好几天的时间才能被找到——我们的确是在和比特与字节之海作战。这本书是关于结对编程技术的,
这项技术既能大大增加我们获得成功的次数,也能大大减少我们遭遇挫折的次数。在与比特和字节作战的
时候,两名程序员看来更容易获得成功。
1.1 结对编程
结对编程是这样一种程序设计实践:两名程序员并肩工作在同一台计算机前,共同探讨设计方案、共
同设计算法、共同编写程序代码、共同完成各种测试。在这两个人当中,被称为“驾驶员”的那个人负责
打字或写出设计方案,被称为“领航员”的另一个人负责其他工作,包括随时观察驾驶员的工作情况,发
现并纠正其操作性和策略性失误。操作性失误包括各种语法错误、打字错误、用错了函数,等等。策略性
失误包括驾驶员偏离了正确方向——即他正在编写的代码不能让这两位搭档到达预定目标——的各种情
况。领航员扮演着战略思想家的角色。我们都曾有过走错路的经历,但如果能够有一位领航员问我们一个
简单的问题——“你能解释一下你为什么这么做吗?”,我们大都能够及时地回到正确的路线上来,领航员
对问题有着更为客观的视角和对事态发展方向有更全面的思考。另一件大好事是驾驶员和领航员至少每隔
45~60 秒就会交流一次——有时只是一句简单的“啊?”定期交换驾驶员和领航员的角色也是非常重要的。
1.2 是否结对,这是个问题
既然你们已经知道什么是结对编程技术了,那么有些读者可能会问这样一个问题:为什么会有人愿意
与别人结对编程搭档?如果你能把本书从头读到尾,我们将告诉你很多条理由。但是我们想利用现在这个
机会把我们亲眼看到过,亲身体验过或者亲耳听到过的结对编程技术的好处告诉你:
1) 质量。由两位搭档合作编写出来的代码有着更少的缺陷。
2)时间。根据我们掌握的数据,两位搭档合作编写出同样高质量的代码所花费的时间通常最多只需要
他们各自独立编程时的一半。这意味着项目的开发周期能够在既不增加整体预算也不降低代码质量的前提
下大大缩短(我们将在第 4 章对这一点做详细讨论)。
3)忠诚度。结对程序员都是快乐的编程搭档,而快乐的员工很少会另谋高就,所以这将提高他们对企
业的忠诚度。
4)信任与团队精神。结对编程技术能够加深编程搭档之间的相互了解并建立信任,这对改善团队的精
神面貌有着莫大的好处。
5)知识交流。结对程序员,尤其是那些搭档并不固定的结对程序员,对项目及其进展情况往往有着更
全面的了解。
6)促进学习。通过观察自己的编程搭档如何分析问题以及如何运用编程语言和软件开发工具去解决问
题,结对程序员将不断地学习到一些新的知识。
这些好处不仅体现在新代码的开发工作中,在老代码的维护或功能扩展工作中也同样有所体现。
1.3 墙上的旁观者
那么,采用结对编程技术的开发团队到底是怎样工作的呢?为了让读者对此有一个直观的认识,请大
家和我们一起变成一只停在墙上的小虫去看看一支这样的团队每天都是如何工作的。这支团队采用了结对
编程技术并建立了结对轮转机制(我们将在第 9 章对结对轮转机制作详细的讨论)。结对轮转机制指的是这
样一种情况:每一组编程搭档都是根据当日(或者在该星期之内)需要完成的具体工作而动态地组合起来
的。这个团队每天都要在刚上班时召开一个短会。这个短会是站着召开的——这是为了强调这个“短”字。
按照顺序,团队中的每个人都要简单的解释一下自己在昨天做了哪些工作、遇到了哪些问题、今天要做些
什么,等等。这种短会在 XP 方法论里被称为“站立式会议”(引自:Auer and Miller,2002),在 SCRUM
方法论里被称为“SCRUM 会议”(引自:Beedle and Schwaber,2002)。这种短会既加强了团队的凝聚力和
各成员之间的沟通,又能以最佳方式确定出各位成员在当日、当日上午或者当日下午与谁搭档。
例子中的团队由 6 名成员组成,他们正在开发一个电子商务软件。在我们旁观的这一天,参加每日例
会的成员只有 5 人,但在中 5 个人围城的圆圈旁的桌子上有一个麦克风,最后一名成员 Chris 的汽车出了故
障,所以他今天将在家里上班。我们来看看 Kimberly、Chris、Brian、Chelsea、Alex 和 Julie 这六个人是如
何开始今天的工作的。
Kimberly:昨天我和 Chelsea 一起编程写了新账号的录入表单。我们完成了这个表单,但我们觉得那
个表单里有几项会与我们的隐私政策相冲突。
Julie(插话道):Kimberly,我今天上午可以和你搭档去解决你所关心的隐私问题。
Kimberly(结束发言):那太好了,Julie。但我们最好能在上午这几个钟头里把这事解决,因为我和
Chelsea 昨天做完那个表单之后还对用来存放账户数据的数据库进行了设计。Chelsea,也许咱俩下午可以
根据我和 Julie 上午做的修改该再把数据做出来。
Chelsea:这样最好。我和 Kimberly 昨天已经把账户录入表单和它的后端数据库做得差不多了,所以
我希望今天下午能和她一起根据 Julie 就隐私政策方面的检查再把它们彻底做好。这样,我上午就可以先
和别人搭档干点其他事情了,我打算编写用来检验这个表单的 JavaScript 脚本。
Alex:这刚好是我和 Brian 昨天对购物车部分做的事。今天上午我就帮 Chelsea 写那个脚本好了。Julie,
也许你今天下午能和我一起把购物车的隐私问题解决掉。
Chris(通过麦克风):对不起,我的汽车今天早晨发动不起来了。幸好我是个 AAA 会员,它们派了辆
拖车把我的车脱去修理了。我和 Julie 昨天一直在处理隐私政策。咱们这几个人里,就属 Julie 最懂得法
律,也最懂得怎样去保护咱们的顾客;要想不让顾客把咱们告的赔了裤子,就得靠 Julie。可这世上能有几
个律师呢——我说这话 Julie 可别在意,咱得让人人都能看懂咱的隐私政策才行!这么说吧,Julie 和我昨
天把隐私政策页面全都弄好了。现在,它不仅是人人都能看懂,而且也符合咱们站点的整体风格。我俩已
经在昨天下午把它发给 BBBOnline 去审批了,他们应该在下星期一回信。我今天的呆在家里,但我想和 Brian
一起做一下 FAQ 页面。Brian,咱俩就用 netmeeting 来干吧,怎么样?
Brian:没问题。Alex 刚才已经讲了,我和他昨天编写了购物车表单的检验脚本。我今天就和 Chris 一
起去做 FAQ 页面好了。Chris 好像对这个页面很不满意呢,对吧,Chris?(笑)
Chris(笑):我可没这么说,我是恨你第一次做这个页面的时候没让我和你搭档。
——会议结束——
现在,6 个人都找到了最适合的工作搭档,那个电子商务软件(而不仅仅是每个人手里的具体工作)将
得到进一步的完善了。接下来,现场的 5 个人坐到了他们各自的结对工作站前,Brian 启动 netmeeting 开始
了与 Chris 的远程合作(我们将在 26 章对远程结对编程技术做详细的讨论)。我们,停在墙上的小虫,飞落
到 Alex 和 Chelsea 面前的显示器上。那是一台很大的液晶显示器,所以他们俩都能清楚地看到其中的显示
内容。Alex 和 Chelsea 正在讨论着新账号表单的检验问题。
Chelsea:我们需要检验这个表单以确保只有“有效”数据才会被发送到数据库去。这个表单里的头两
项是 Lastname(姓氏)和 Firstname(人名)。说老实话,我以前没干过这个。但我想这个检验应该确保用
户输入的都是字母而不是数字或特殊字符——空格也不行。Alex,我认为我们应该这么干:先把用户可能
会做出来的各种傻事列成一份清单,再去编写对付这些傻事的函数。
Alex:我和 Brian 昨天在编写购物车表单检验脚本时就是这么干的,而且我们已经把有关函数收集在
一个文件里了。我马上就能把这个文件找出来,你只要把那个文件包括到你的脚本里就行了。(一边说一边
抓过键盘。)诺,找到了。你看,我们定义了 isWhitespace、isDigit、isLetter、checkString 以及其他
几个来检验表单项的函数。
Chelsea(一边唱,一边拿过键盘开始打字): <script language= ” javaScript ” >function
validateForm(){
Alex:一次检查一个表单项是不是要比一次检查整个表单好一点?
Chelsea:这并没有多大区别。我想把表单检验工作写成一个“大”函数,再让这个“大”函数去调用
各种“小”函数。无论如何,只有在用户点击“submit”按钮提交了整个表单之后,对它的检验工作才能
开始。
Alex:对啊,你说的没错。
Chelsea(继续打字):if(checkStrings(LastName)) then
Alex:等一下,这个函数名应该是 checkString,不是 checkStrings——它尾巴上没有“s”。
Chelsea:多谢,你的眼神还真不错。
…….
刚编写了不多的几行代码,Alex 和 Chelsea 之间就已经发生了文件共享(这将节省好几个小时、甚至好
几天的时间)、询问、建议、交换看法等事件。我相信,Alex 和 Chelsea 合作完成的表单肯定要比他们中的
任何一个人独自工作而得到的结果更正确、更健壮——有了这种配合,他们肯定能把那些“笨”用户可能
做出的“傻事”都考虑周全。
1.4 结对编程技术的早期实践
有很多人声称他们早在多年以前就开始采用结对编程技术了:
z Fred Brooks,《The Mythical Man》一书的作者,在给 Laurie 的一封电子邮件里说到:“我第一次尝
试结对编程技术是在我读研究生的时候(1953~1956 年),我当时的搭档是我的研究生同学 Bill
Wright。我们一起编写了 1500 行毫无缺陷的代码,它第一次试运行就通过了。”
z Dick Gabriel ,Common Lisp 的创始人,也是把模式(pattern)和模式语言(pattern Language) 介
绍给软件行业的人,他早在 20 世纪 70 年代就写出了结对编程技术方面的文章。他在这方面的个
人经历将附在本章的末尾。
z Larry Constantine,150 余篇技术文章和 16 本书的作者,在他发表于 20 世纪 80 年代初的一篇文章
里说 Withtsmith 公司里的“动态搭档”能够以前所未有的速度编写出漏洞更少的代码来。他指出,
两位聪明人的头脑,再加上两位互相信任的程序员之间的交流,使代码质量得到了极大的提高。
他最终的结论是:让两位程序员合作完成同一项工作绝不是一种浪费,相反,而是一条效率更高、
质量更优的捷径。
z 在对贝尔实验室的 Pasteur 项目(Pasteur 项目队 50 多个高效率的软件开发组织的企业模式进行了研
究,它使用了与社会学和人类学研究相类似的数据采集和分析技术。)进行总结研究之后,软件模
式(software pattern)运动中最有影响力的人物之一 James Coplien 于 1995 年提出了“结对开发”的
企业模式。在总结这一模式的时候 Jim 是这样说的:“有时候,人们只是在能够得到帮助的情况下
才会觉得自己能够解决某个问题。有些问题是任何个人都无力解决的。。。。。。【这一问题的解决方
案是】让彼此‘兼容’的设计人员结为搭档,他们的合作将比两个人各自独立工作产生更大的效
益。。。。。。【采用这种模式的结果是】一个效率更高的开发过程。两位搭档要比单独一位开发者犯
的错误少得多。”
z 本书作者 Bob Kessler 是在与 Martin Griss,《Software Reuse》一书的合著者(这本书的另两位作者
是 Ivar Jacobson 和 Patrick Jonsson),结对编程了很多年以后才知道这项技术是有个专有名称的。
z 随着 Kent Beck 提出的 Extreme Programming(XP)方法论为越来越多的程序员所接受,结对程序
员的队伍越来越壮大(我们将在第 24 章介绍 XP 方法论)。XP 已经清晰地向我们展示出结对编程
技术的优越性。
这些成功的案促使我们对结对编程实践活动进行研究。在对大量详实可靠的数据进行研究分析之后,
我们得出了这样一个结论:结对编程技术是一种不需要增加多少投入就能够大幅度提高软件产品质量的手
段。根据了解的情况,我们相信结对编程技术几乎能与所有的软件开发方法论相结合——本书的第四部分
就给出了两个这样的案例,并就结对编程技术具体实施过程中所必须注意的一些问题进行探讨。
1.5 有言在先
“结对编程技术”中的“编程”可以是软件开发过程中的任何一个阶段(设计、调试、测试、等等),
而不是仅限于编写程序代码。也就是说,结对编程技术覆盖了结对设计、结对调试、结对测试等各个方面。
事实上,有两项研究表明,结对技术对软件的分析和设计阶段也有着至关重要的意义。我们认为,软件开
发过程中的各个阶段都应该坚持采用结对技术,尤其是在项目比较复杂的时候。任务越复杂,就越需要两
个人的智慧。
在进入本书正题之前,还有一点要注意:我们认为,绝不能把结对编程技术强加于人。我们发现,在
刚开始的时候,很多人都会拒绝接受结对编程技术——打破长期形成的已有习惯并蜕变成一个善于交流与
合作的人并不是件容易的事。但那些尝试过这项技术的人们几乎都认为它要优于独自工作。我们还注意到,
有些人宁愿退出团队也不愿意被迫与别人搭档。我们希望结对编程技术的推广工作能像金字塔式营销一样:
先从最热衷于此的人们开始,让这些人告诉自己的朋友们那有多么美妙,再让这些朋友们告诉他们的朋友
们,其最终结果是不难想象的。
最后,还要注意:结对编程技术并非人人适用,独行侠也是团队里的一份子。
参考资料:
Allen,Adrian. “An investigation into Potential Reasons Why Pair Programming is Not Widely Adopted by
Programmers as a Standard Development Practice When Developing Software,” Technical Report, University of
Cape Town, October 2001.
Auer, k. and Miller, R.. (2002). Extreme programming applied: Playing to win, Addsion-Wesley.
Beck, k. (2000) .Extreme programming Explained: embrace change, Addison-Wesley.
Beedle,M, and schwaber,k.(2001). Agile software development with scrum, Prentice Hall.
Brooks,F.p.(19950). The mythical man month anniversary editon, Addsion-wesley.
Constantine ,L,L.(1995). Constantine on peopleware, Yourdon press
Coplien J.O.(1995).”A development Process generative pattern Language,” in pattern languages of program
design, James O. Coplinen and Douglas C. Schmidt, eds., Addison-Wesley, 183-237.
Williams, L.A. (2000). “The collaborative software process.”, Ph.D. dissertation, University of Utah.
Williams, L.Kessler,R., Cunningham,W., and Jeffries,R.(2000). “Strengthening the case for
pair-programming .” IEEE Software,july/august 2000,19-25
结对编程经验谈(作者:Dick Gabriel)
1972 至 1973 年间,也就是我在 MIT(美国麻省理工学院)人工智能实验工作的那段时间里,结对编
程在那里是一件很平常的事。后来,当我在 University of Illionis(伊利诺斯大学)和 Stanford University(斯坦福
大学)工作时,为了把 MIT Lisp 系统(即 MacLisp)移植到我在这两所大学里所使用的操作系统上,我和 Jone
White 结为编程搭档。或者是 Jhon 到我这儿来,或者是我回 Cambrige 城去,总之,我们俩会并肩坐在他
或者我的终端前一起编程。在我们这组搭档中,驾驶员将由更熟悉代码用途的那个人来担任。请注意,我
们是在对一个现有的大型系统进行补充和修改。
我在 1984 年启动了 Lucid 计划,我们开始计划如何在 9 个月内作出一个 Common Lisp 的具体实现来。
我们聘请 Marin Brooks 做顾问来帮助我们定义整个开发过程。我们按功能把整个项目分解成一些独立的功
能组件,再让 15 名程序员分别负责实现某个功能组件中的各个模块。我负责实现内存管理模块,其他模块
包括编译器,解释器,映射函数,数组,调试器,等等。根据设计方案,这些模块虽然相互独立,但彼此
并不是毫无关系的。我们给负责实现各个模块的人安排了一位助手,而这位助手的职责就是密切配合该模
块的“主人”开展工作。每个模块的开发曲线都是一样的:现在纸上写出一个设计方案,然后在纸上实现
并测试这个方案,然后再编写程序代码和测试案例,最后再把模块集成在一起。集成工作相当频繁,有时
是一天一次,有时甚至是一天数次——只要有所进展,我们就会进行一次集成。
设计方案有模块主人和他的助手共同制定,但绝大部分内容由模块主人执笔。每一个设计方案都要进过整
个团队的评审并获得一致通过后才能动手实现。程序代码的编写工作大都由两位搭档共同参与完成,偶尔
也会有一两天的时间是由模块主人独自把代码敲入机器。但我们要求那位助手必须在代码被编写出来后的
一天之内对它进行审查。我们的开发团队还专门成立了一个代码审查小组,负责在集成工作开始之前对有
关代码做逐行的最终审查。
各开发小组随时保持接触以便通报彼此的进展情况。我们几乎每天(通常在午餐时间)都召开一个非正式
全体会议,每星期还要召开一个正式的全体会议。
这种“主人-助手”机制与当今的结对编程技术几乎没什么两样,唯一的区别是我们那时候并不要求那
位助手必须一直坐在主人的旁边。每个助手本身还是另一个组模块的主人,而他的助手可能是另外一个人。
我们的那次经历完全可以看作是结对编程技术在大型项目上的一次经典运用。
除了人们现在为结对编程技术而总结出来的那些因素外,我们当初采用“主人-助手”机制的理由还包
括需要为每个模块准备一名第二人选以避免因模块主人无法上班而拖延工期——我们的确害怕出现车祸等
意外。此外,我们当时是在对一个大约 50 万行代码的系统进行商业化开发,而全部工作又必须按严格的质
量要求在 9 个月内完成,所以我们不得不在编写模块代码的同时编写测试案例。并且,那 15 名程序员在各
自的职业生涯里都曾编写过某个 Lisp 系统的一部分或者是全部,我们当然要最大限度的利用其经验了。
我有几篇技术论文是以“结对写作”方式完成的。它与结对编程工作很相似,只是两个搭档是在进行
写作而已。由 Thomas J. Bergin 和 Richard. G .Gibson 主编的《History of Programming Languages II》书
中的“The Evolution of Lisp
”部分就是我和 Guy L.Steel,Jr. 以这种方式完成的。
剩余98页未读,继续阅读
资源评论
- littleblueb2013-07-18正准备在工作中采用这个,很好的guide
- 红色标记2012-09-26有独到的见解,对我有一定的帮助。
- aqxy2012-06-12很好,正是我想要找的,多谢分享。对考虑是否可以在工作中借鉴结对编程技术有参考。
douwf
- 粉丝: 4
- 资源: 8
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功