pHP信电系网站建设设计极限编程（中英对照）.doc

pHP信电系网站建设设计极限编程（中英对照） Extreme Programming（极限编程）As wehave exploredin severalissues of eAD,the twomost pressingissues ininformation technologytoday are:正如我们在eAD的若干期中探究的那样，当今信息技术中最迫切的两个问题是:How dowe deliverfunctionality tobusiness clientsquickly?如何能快速地向商业用户交付功能？How dowe keepup withnear-continuous change?如何才能跟上近乎连续的变化?Change ischanging.Not onlydoes thepace of change continueto aelerate,but,as theSeptember issue ofeADpointed out,organizations arehaving todeal withdifferent typesof change-disruptive changeand punctuated equilibrium.Disruptive technologies,like personalputers in the early1980s,impact anindustry(in thecase ofPCs,several relatedindustries),while apunctuated equilibrium-a massiveintervention into an ecosystemor aneconomy-impacts avery largenumber ofspecies,or panies.The Inter,which hasbee thebackbone fore-merce ande-business,has disrupteda widerange ofindustries-more apunctuatedequilibriumthan adisruption.变化本身也在不断地变化中。 不仅仅是变化的速度在不断地提高，而且，如eAD的10月中所指出的，组织正在不得不应付各种类型的变化-剧变与不断被打破的平衡。 产生剧变的技术，象在80年代早期的个人计算机，冲击了一个工业(PC机以及若干相关的工业)而不时打断的平衡-一个对生态系统或者对整个经济产生巨大影响的介入-则影响了无数的物种，或者说，公司。 已经成为电子商务支柱的Inter,就已使大范围的行业产生剧变-更多的是打断的平衡而不仅仅是一次剧变。 When wholebusiness models are changing,when time-to-market bees the mantraof panies,when flexibilityand interconnectedness are demandedfrom even the moststaid organization,it isthen that we mustexamine everyaspect ofhow businessis managed,customers aredelighted,and products are developed.当整个商业模式正在发生变化，当时间意味着市场正成为公司的咒语，当适应性与互连性正在成为甚至是最呆板的组织的需要的时候，我们将有必要检查以下的每一个方面:商业是如何管理的，客户为什么而感到高兴，以及产品是如何开发的。 The Extreme Programming movementhas beena subsetof theobject-oriented(OO)programming munityfor severalyears,but hasrecently attractedmore attention,especially withthe recentrelease ofKent Becks newbook Extreme Programming Explained:Embrace Change.Dont beput offby thesomewhatin-your-facemoniker ofExtreme Programming(XP topractitioners).Although Beckdoesnt claimthat practicessuch aspair programming and incremental planning originatedwith XP,there aresome veryinteresting,and I think important,concepts articulatedby XP.Theresalot oftalk todayabout change,but XP has somepretty goodideas about how toactually doit.Hence thesubtitle,Embrace Change.终极编程(ExtremeProgramming)运动成为面向对象编程这个团体的一部分已经有数年了，但是直到最近才引起了越来越多的注意，特别是最近Kent Beck的终极编程释义:拥抱变化(ExtremeProgrammingExplained:Embrace Change)一书的出版。 千万不要因为终极编程(业内人简称为XP)这一称呼而对它产生反感。 尽管Beck没有说象配对编程(pair programming)，增量式计划(incrementalplanning)之类的XP,但是仍然有一些非常有趣的，我认为也是很重要的概念可以借用XP来表达。 现有有许多关于变化的讨论，但是XP却有许多如何实际去做的非常好的想法。 也就是这个副标题:拥抱变化。 There is a tendency,particularly byrigorous methodologists,to dismissanything lessponderous thanthe Capability Maturity Model(CMM)or maybethe InternationalOrganization forStandardizations standards,as hacking.The connotation:hacking promotesdoing rather than thinkingand thereforeresults inlow quality.This is an easyway todismiss practices that conflictwith ones ownassumptions about the world.有一种趋势，特别在那些严格的方法论者中，希望剔除那些与能力成熟度模型(CapabilityMaturityModel CMM)或者是国际标准化组织的标准相比不那么笨重的方法，比如象hacking.注释:hacking推崇行动而不是思考从而导致了较低的质量。 剔除与某人关于这个世界的假设相冲突的实践，这倒不失为一种简单的方法。 Looked atanother way,XP maybe apotential pieceof apuzzle Ive beenwriting aboutover thepast18months.Turbulent timesgive riseto newproblems that,in turn,give riseto new practices-newpractices that oftenfly in the faceof conventional wisdom butsurvive becausethey arebetter adaptedto thenew reality.There areat leastfour practicesI wouldassign tothis category:从另一个角度来看XP，它倒可能是一个难题的某个潜在的部分，这个一个我在过去18个月中一直都在写的内容。 混乱的时期产生新的问题，而后者又导致了新的实践-新的实践公然违抗传统的知识，但却得以幸存下来是因为它们能更好地适应这个新的现实世界。 至少有四种实践方式我觉得是属于这个范畴的:XP-the focus of this issue ofeAD XP-eAD本期的焦点Lean development-discussed in the November1998issue ofeAD轻量级的开发(Lean development)-已经在eAD199811月中讨论Crystal Lightmethods-mentioned in the November1999issue ofeAD andfurther discussedin thisissue轻量级的Crystal方法(Crystal Lightmethods)-曾在eAD1999年11月提到，在本期中将做进一步的讨论Adaptive software development-described inthe August1998issueofeAD(then calledApplication DevelopmentStrategies-ADS)自适应软件开发(Adaptive software development)-在eAD1998年8月中描述过(当时叫做应用开发策略Application DevelopmentStrategies-ADS)Although there are differencesin eachof thesepractices,there arealso similarities:they eachdescribe variationsfrom theconventionalwisdomabouthow to approachsoftware development.Whereas leanand adaptivedevelopment practicestarget strategicand projectmanagement,XP bringsits differingworld viewto therealm of the developerand tester.尽管这些实践中存在着差异，但是它们中也有相似的地方:它们都描述了与传统软件开发不同的方法。 虽然轻量级的开发与自适应开发针对的是战略与项目管理的，但是XP却用不同的视角将开发方法带入了程序员与测试员的领域。 Much of XP isderived fromgood practicesthat have been aroundfor along time.None of the ideasin XPare new.Most areas oldas programming,Beck offersto readersinthepreface tohis book.I mightdiffer with Beck inone respect:although the practices XP uses arent new,the conceptualfoundation andhow they are meldedtogether greatlyenhance theseolderpractices.Ithinktherearefour criticalideas totake away from XP(in addition toanumber ofother goodideas):XP中许多部分其实都于业已存在的那些优秀的开发实践。 XP中没有一个想法是全新的。 大多数想法产生的时间实际上和编程一样古老Beck在他书中的前言中这样说道。 但是我在某一个方面考虑的也许与Beck有所不同尽管XP所用的实践方式不是全新的，但是概念的建立以及它们如何融合在一起极大地增强了这些老的实践。 我想(除了许多其它的好思想外，还)可以从XP中提炼出四个关键的思想:The costof change变化的成本Refactoring重构Collaboration协作Simplicity简单化But first,I discusssome XPbasics:the dozenpracticesthatdefine XP.但是首先，我们来讨论XP的基础:那十二个用于XP的实践方式。 XP-The BasicsXP基础I mustadmit thatone thingI likeabout XPs principalfigures istheir lackof pretension.XP proponentsare carefulto articulatewhere theythink XP is appropriateand whereit isnot.While practitionerslike Beckand RonJeffries mayenvision thatXPhaswider applicability,they aregenerally circumspectabout theirclaims.For example,both areclear aboutXPs applicabilityto small(less than10people),co-located teams(with whichthey havedirect experience);they dont tryto convincepeople that the practiceswill work for teamsof200.我必须承认一件事情，就是我喜欢XP的原因应该是它没有其他的那些花哨的东西。 支持XP的人们总是会向你指出XP适合的地方以及他的某些局限性。 而XP的实践者Beck以及Ron Jeffties却相信XP会有更广泛的应用前景。 他们通常对于自己的要求都是很谨慎的。 例如小的（小于10人），公司局部（他们有直接的经验）两者对于XP的适应性都是很清楚的；他们并没有试图让人们相信XP可以适用于一个200人的团队。 The Project工程The mostprominent XPproject reportedontodate isthe Chrysler Comprehensive Compensation system(the C3project)that wasinitiated inthe mid-1990s andconverted toan XPproject in1997.Jeffries,one of theThree Extremoes(withBeckand Ward Cunningham),and Ispent severalhours talkingabout the C3project andother XP issues atthe recentMiller FreemanSoftware Developerconference inWashington,DC,USA.最为著名的XP项目是克莱斯勒综合补偿系统（称为C3工程），它在上个世纪的90年代中期开始，到1997演变为XP。 Jeffries,是终极编程三人组之一（另外两个是Beck同WardCunningham）。 我在华盛顿特区同自由软件人谈论了有关C3的以及其他与XP项目有关的东西。 注解ChryslerComprehensiveCompensationsystem克莱斯勒综合补偿系统Originally,the C3project wasconceived as an OOprogramming project,specifically usingSmalltalk.Beck,a well-known Smalltalkexpert,was calledin toconsult onSmalltalk performanceoptimization,and the project wastransformed intoa pilotof OO(XP)practices afterthe originalproject wasdeemed unreclaimable.Beck broughtin Jeffriesto assiston amore full-time basis,and Jeffriesworked withthe C3team untilspring1999.The initialrequirements wereto handlethe monthlypayroll ofsome10,000salaried employees.The systemconsists of approximately2,000classes and30,000methods andwas readywithin areasonable toleranceperiod of the plannedschedule.最初，C3是一个基于OO（面向对象技术）的开发项目，尤其是它采用Smaltalk语言进行开发。 （Smaltalk Xerox公司开发的一种高级程序设计语言,它支持和鼠标合用的选项屏驱动式应用程序,有助于建立便于使用的计算机程序。 ）作为著名的Smalltalk专家，Beck被邀请来讨论有关SmalTalk性能优化的问题，并且在原项目被认为不可救要的时候将其变为一个采用面向对象OO（XP）方法的试验性项目。 Beck并且带来了Jeffries用于帮助那些基本的东西，Jeffries在C3组一直干到1999年的春天。 最开始的需求是要做一个对约10，000个雇员每月薪水发放进行管理的系统。 这个系统由大约2，000个类以及30，000个方法构成，并且在计划方面提供有合理的容忍度As wetalked,I askedJeffries howsuess on theC3project translatedinto XPuse onother ChryslerIT projects.His grin told meall Ineeded toknow.Ivebeeninvolved inenough rapidapplication development(RAD)projects forlarge IT organizations overthe yearsto understandwhy suessdoes notconsistently translateinto aeptance.There arealways at least ahundred verygood reasonswhy suessat RAD,or XP,or leandevelopment,or otherout-of-the-box approachesdoesnt translateinto wideruse-but moreon thisissue later.正向我们所谈到，我问Jeffries他怎样成功的将C3变为XP并应用到其他的克莱斯勒IT项目。 他笑着告诉了我。 多年来我为许多大型IT组织开发了不少RAD系统（快速原型开发），因此我知道为什么我们无法将成功的经验运用于其它项目中.对于RAD,XP,轻量级的开发以及其它一些未得到广泛应用的方法,它们成功的原因至少有一百条.Practices实践One thingto keepin mindis thatXP practices are intendedfor usewith small,co-located teams.They thereforetend towardminimalism,at leastas faras artifactsother thancode and test casesare concerned.The presentationofXPs practiceshave bothpositive andnegative aspects.At onelevel,they soundlike rules-do this,dont dothat.Beck explainsthat thepractices aremore likeguidelines thanrules,guidelines thatare pliabledepending on the situation.However,some,like the40-hour week,can eoff asa littlepreachy.Jeffries makesthe pointthat thepractices alsointeract,counterbalance,and reinforceeach other,such thatpicking andchoosing whichto useand whichto discardcan betricky.应记住的一件事情就是我们应倾向于在小型的,局部的团队中运用XP。 除了代码与测试用例外,尽量减少有些的影响。 XP的实践既有正面的表现,也有负面的。 在某些方面看来，他们听起来就像一堆规则，要做这个，不要做那个。 对此Beck解释道,与规则相比,XP更像是指导方针，一个灵活的依赖于具体环境的开发方针。 但是诸如每周工作40小时等看起来可能会感觉续续道道。 Jeffries使得实践也会互相作用的，平衡，互相加强。 以至于挑选使用的同丢弃的都是棘手的事情。 The planninggame.XPs planningapproach mirrorsthat ofmost iterativeRAD approachesto projects.Short,three-week cycles,frequent updates,splitting businessand technicalpriorities,and assigningstories(a storydefines aparticular featurerequirement andis displayedin asimple cardformat)all defineXPs approach to planning.计划的制定XP中关于制定计划的实现方法中可以反映出大多数迭代式RAD项目的特点。 短期的，每三周为一个循环，频繁地更新，按优先级划分任务与技术，分配stories（一个story定义了一个特殊的功能需求并以一种简单的方式记录在卡片上），所有的这些就是构成了XP中的计划。 Small releases.Every releaseshould be as smallas possible,containing themost valuablebusiness requirements,states Beck.This mirrorstwo ofTom Gilbs principles of evolutionarydelivery fromhis bookPrinciples ofSoftware EngineeringManagement:All largeprojects arecapable ofbeing dividedinto manyuseful partialresult steps,andEvolutionary stepsshould bedelivered onthe principleof thejuiciest onenext.小版本每个版本应该尽可能的小，而且包含最有商业价值的需求，Beck如是说。 这也反映了Tom Gilb在他的书中提到的关于渐进式发布的两点所有的大的项目都可以被分为局部的,有用的小的步骤以及进化的步骤会传递到下一级。 Small releasesprovide thesense ofaomplishment thatis oftenmissing inlong projectsas wellas morefrequent(and morerelevant)feedback.However,a developmentteam needs to alsoconsider the difference betweenreleaseandreleasable.The costof eachrelease-installation,training,conversions-needsto be factoredinto whether or not the productproduced atthe endofacycle isactually releasedto theend useror issimply declaredto bein areleasable state.小型版本的发布意味着具有在大型项目中经常缺少的频繁的反馈的实现.。 然而，一个开发小组当然需要考虑到发布同可发布的不同。 无论是否是最终的版本发布还是一个简单的可发行版本的发布,都需要付出安装，培训，转化等代价。 Metaphor.XPs useof thetermsmetaphorandstorytake a little wearinginto bee fortable.However,both termshelp makethe technologymore understandablein humanterms,especially toclients.At onelevel,metaphor andarchitecture aresynonyms-they areboth intendedto providea broadview of the projects goal.But architecturesoften getbogged downin symbolsand connections.XP usesmetaphorin anattempt todefine anoverall coherenttheme towhich bothdevelopers andbusiness clientscan relate.The metaphordescribes thebroad sweepof the project,while storiesare usedto describeindividual features.隐喻在XP中隐喻以及story的使用可能会让人有一点不舒服。 但是，这些术语的使用可以帮助我们以一种更人性化的方式加以理解，尤其是对客户而言。 从某种程度上来说，隐喻同体系结构是同意语他们都着重于从全局描述一个项目。 但是体系结构经常会陷于符号与连接的泥潭。 而XP使用隐喻定义一个从开发者到商业客户都可联系的全面一致的主题。 隐喻用于描述项目全面的面貌，而Story用于描述个别具体的特征。 Simple design.Simple designhas twoparts.One,design for the functionalitythat hasbeen defined,not forpotential futurefunctionality.Two,create thebest design that candeliver thatfunctionality.In otherwords,dont guessabout the future:create thebest(simple)design you can today.If youbelieve thatthefutureis uncertain,and youbelieve thatyoucancheaply changeyour mind,then puttingin functionalityon speculationis crazy,writes Beck.Put inwhat you need whenyouneedit.简单的设计简单的设计包含两个部分。 一，为已定义的功能进行设计，而不是为潜在地未来可能的功能进行设计。 二，创建最佳的可以实现功能的设计。 换句话说，不用管未来会是怎样，只创建一个目前为止可以实现的最好的设计。 如果你相信未来是不确定的，并且你相信你可以很方便的改变你的主意的话，那么对未来功能的考虑是危险的。 Beck写到。 只有在你真正需要的时候才去做In theearly1980s,I published an articlein Datamationmagazine titledSynchronizing Datawith Reality.The gistof thearticle wasthat dataquality isa function of use,not captureand storage.Furthermore,I saidthat datathat wasnot systematicallyused wouldrapidly gobad.Data qualityisa functionofsystematic usage,not anticipatory design.Trying toanticipate whatdata wewill needinthefuture onlyleads usto designfor datathatwewill probablynever use;even thedata wedid guesscorrectly onwont becorrect anyway.XPs simpledesign approachmirrors thesame concepts.As describedlater inthis article,this doesnt mean that noanticipatorydesignever happens;it doesmeanthatthe economicsof anticipatorydesign changesdramatically.在二十世纪八十年代，我发表了一篇有关自动化资料管理的文章实际的同步数据文章的意思是说数据的质量是使用功能，不是捕捉与存储。 此外，我说数据如果不是很系统的使用便会变坏。 数据质量是系统使用的功能，不是可预料的设计。 无论预期的对还是错，试着设计一个我们从来都不会用到的数据，最终结果很可能我们一次也不会用到它们。 XP的简单设计方法反映了相同的观点。 如在本文后来所描述的那样，这并不意味着不需要预测，而是说为预测的内容所做的设计一旦发生变化，其导致的代价是十分巨大的。 Refactoring.If Ihad topick ohing thatsets XPapart fromother approaches,it wouldbe refactoring-the ongoingredesign ofsoftware toimprove itsresponsiveness tochange.RAD approacheshave oftenbeen associatedwith littleor nodesign;XP shouldbe thoughtof ascontinuous design.In timesof rapid,constant change,much moreattention needstobefocused onrefactoring.See thesectionsRefactoringandData Refactoring,below.重构如果我不得不找出一个能够将XP和其他方法区别开来的东西那就是重构不断的软件再设计以改进它对于变化的反应。 RAD方法常常很少甚至根本不与设计相关；XP应当被看作持续设计。 当变化既快而且频繁的时候，应投入更多的精力于重构之上。 参见下面的重构和数据重构部分。 Testing.XPisfull ofinteresting twiststhat encourageone tothink-for example,how aboutTest and then code?Ive workedwith software panies anda fewITorganizationsin whichprogrammer performancewas measured on linesof codedelivered and testing wasmeasuredondefects found-neither sidewas motivatedto reducethe numberof defectsprior totesting.XPusestwo typesof testing:unit andfunctional.However,thepracticefor unittesting involvesdeveloping thetest forthe featureprior towriting thecode andfurther statesthatthetests shouldbe automated.Once thecode iswritten,it isimmediately subjectedto thetest suiteinstant feedback.测试XP充满发人深思的有趣的难题。 例如什么是先测试后编码？我曾经同软件公司和一些IT机构一起工作，在那儿是通过代码的行数来对程序员的绩效加以考核，而测试的绩效则是通过发现的缺陷的数量来考核的。 这两种方法都不能鼓励减少测试前产生的缺陷的数量。 XP使用两种测试单元测试和功能测试。 单元测试要求在写代码之前就开发出相应功能的测试方法，并并测试应当是自动化的。 代码一完成，它就被立即用有关测试集加以测试，从而能立即得到反馈。 The mostactive discussiongroup onXP remainsthe Wiki exchange(XPisa pieceoftheoverall discussionabout patterns).One ofthe discussionscenters arounda lifecycleof Listen(requirements)Test CodeDesign.Listen closelyto customerswhile gatheringtheir requirements.Develop test cases.Code theobjects(using pair programming).Design(or refactor)as moreobjects areadded to the system.This seeminglyconvoluted lifecyclebegins tomake senseonly inan environmentin whichchange dominates.最活跃的XP讨论组仍然是Wikiexchange（XP是关于pattern总体讨论的一部分），其中的一个讨论围绕听取（需求）-测试-代码-设计的生命周期。 贴近客户聆听并收集他们的需求。 开发测试用例（test cases）。 完成对象编码（使用配对编程）。 当更多对象被加入系统时进行设计（或重构）。 这个看起来混乱不堪的生命周期仅仅在经常变化的环境下才有意义。 Pair programming.One ofthe fewsoftware engineeringpracticesthatenjoys near-universal aeptance(atleastin theory)and hasbeen wellmeasured issoftware inspections(also referredto asreviews orwalkthroughs).At theirbest,inspections arecollaborative interactionsthat speedlearning asmuch as they uncoverdefects.One ofthe lesser-known statisticsabout inspectionsis thatalthough theyare verycost effectivein uncoveringdefects,theyareeven moreeffective atpreventing defectsinthefirst placethrough the teams ongoinglearning andincorporation ofbetter programmingpractices.配对编程软件（还是直接用Inspection为好？）（也称审查或走查）也是被广为接受（至少在理论上）和有效度量的少数软件工程实践之一。 在最好情况下，Inspection这种协同交互的检查能够加速学习，同时发现缺陷。 一个较少被知道的关于Inspection的统计数据是尽管它在发现缺陷方面非常有效，但通过团队对于好的开发实践持续的学习和协作，可以更好的在第一时间预防缺陷。 One softwarepany clientI workedwith citedan internalstudy thatshowed thatthe amountof timeto isolatedefects was15hours perdefect withtesting,2-3hours perdefect usinginspections,and15minutes perdefect byfinding thedefect beforeit gotto theinspection.The latterfigure arisesfrom theongoing teamlearning engenderedby regularinspections.Pair programmingtakes this to thenext step-rather thanthe incrementallearning usinginspections,why notcontinuous learningusing pair programming?一家我工作过的软件公司客户引用一个内部研究结果，表明在测试阶段发现一个缺陷需15小时，在Inspection阶段发现一个缺陷则需23小时，而在Inspection之前发现缺陷只需15分钟。 后面的数据于产生于常规审查的持续的团队学习。 配对编程将这个带入下一步与其用Inspection来递增式学习，为什么不用配对编程来学习呢？Pair programmingisadialog betweentwo peopletrying tosimultaneously programand understandhowtoprogram better,writes Beck.Having twopeople sittingin frontofthesame terminal(one enteringcode ortest cases,one reviewingand thinking)creates acontinuous,dynamic interchange.Research conductedby LaurieWilliams forher doctoraldissertation atthe Universityof Utahconfirm thatpair programmings benefitsarent justwishful thinking(see Resourcesand References).配对编程是两个人试图同时编程和理解如何更好编程的一种对话，Beck写道。 让两个人同时坐在一台终端前面（一个人敲代码或测试用例，一个人审查和思考）产生一种持续的、动态的交流。 Williams在犹他大学进行的博士论文研究证明了配对编程不仅仅是一种美好的想法而且确有实效。 （参见资源和参考）Collective ownership.XP definescollective ownership as thepractice thatanyone ontheprojectteam canchange anyofthecode atany time.For manyprogrammers,and certainlyfor manymanagers,the prospectof munal code raisesconcerns,ranging fromI dont wantthose bozoschanging mycodetoWho doI blamewhen problemsarise?C