结对编程技术

Node774

贡献于2012-10-19

字数:0 关键词:

第一部分 结对编程技术理论 从表面上看,结对编程技术只是一个非常简单的概念:两名程序员使用同一台计算机去完成同一项任 务。 如果事情真的如此简单,我们也就用不着写这样一本书了。结对编程技术将涉及到各具特点得人,这 些人和这些人的特点已经因为常年的生活与工作而固定下来,让他们相信结对编程比独自工作更好并不是 件容易的事。软件开发团队的成员几乎都是些“独行侠”,让他们放弃长年养成的工作习惯而与其他人分享 荣誉是很困难的。每位项目经理的手下都有那么一两位与别人老死不相往来的程序员。那么,项目经理为 什么要把程序员结对组合在一起呢?要知道,团队文化是很难改变的。 我们将尝试回答:结对编程技术为什么能帮助你的团队取得最大成就并使之适应这种企业文化方面的 改变。 第 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(一边唱,一边拿过键盘开始打字):