极限编程(ExtremeProgramming，以下简称XP）是软件开发中的一个方法学。它让用户、商人、程序员和计算机能够有效的沟通。Perl作为一种动态开发语言，给极限编程小组的有效沟通，带来了不可思议的改变。在这个婚姻里面，Perl是修理和干活的一方，而XP则是协调和帮助的一方。这个结合让你可以有效地编写强壮的软件。

好像任何美满的婚姻一样，这个ExtremePerl的家庭成员都彼此的支持。例如XP让商人编写测试用例，而Perl让商人用他们自己的语言和工具来测试。绝大多数Perl用来运行测试，而XP则让程序员在开始编码之前就先定义单元测试的对象。在这本书里，你还会看到更多的Perl和XP彼此扶持的例子。正是这些使得ExtremePerl的应用更加强壮。

这本书邀请Perl开发人员和他们的客户用一个崭新的角度来看待软件开发过程。客户或广义上的商人会明白在高效和善变的需求分析过程中XP是如何促进开发人员和客户的沟通的。开发人员会明白XP对团队协作、渐进测试和逐步设计的关注是为了让他们能更多的为自己的手艺自豪。众多的例子用来说明ExtremePerl是如何操作的，包括最后一章对完整可用的应用程序的开发过程的描述。

给商人和用户

XP使你对参与的项目都承担客户的责任。这是对教条的一种解脱。你不用学习用例建模、对象建模或者甚至时尚建模。你在一张纸上面写下你的需求。甚至还可以画画，尽管程序员可能不希望你用彩色蜡笔来画。

作为用户，你也必需用合一的语调说话。你可以自由决定对需求讨论的详细程度，但是最后你总得用自己的语言来清晰地描述出来，这也就是所谓的故事。所有的不一致意见都必须在扮家家的时候解决掉。而所谓的扮家家，就是你和程序员共同决定每个功能对应开发时间的过程。

XP要求你改变思路，这是你要花时间适应的。你得总是和程序员在一起。程序员可不是心理学专家，要是他们错误理解了你的需求或者你觉得他们实作的某个内容不大对劲，那么你就得立刻给出回应。

最棒的是你总可以立刻结束进展。程序员总是用最简单的方法解决问题，你可能觉得难以置信，但问题的确经常在几周内得到解决。没有别的方法比这个更加直接地保证你的需求进入了软件里面，这正是你要做的活。每个人都被一个可用的软件驱动来工作。

给程序员和他们的经理

编程的角色在XP里面非常广泛，程序员负责倾听客户的需求，并且响应客户需求变化的动态。

对XP来说你得实实在在，不能有不确定的估计或者漫无边际的猜测。例如当客户想要加入国际化的功能的时候，你得很清楚这其中的代价的，你得告诉他为了那些功能要需要额外的多少时间。

XP的项目经理是教练也是跟踪者。程序员做完所有的工作，教练在帮边指导和欣赏。如果一切顺利，跟踪的活也很有趣。XP的12个简单实践里面已经有了很多的检查和平衡。然而有时候教练和跟踪者还得额外提醒程序员如何有效的使用这些实践。

编码是XP项目的核心手艺。要按照XP做你得喜欢编码。好在Perl的编码很有趣也很容易。XP在Perl编码的实践中加入了少量的规则，这使你开发的速度和质量都有所提高。

XP是面镜子。你勤快的重构代码，就会得到高质量的软件。这意味着你得修改那些差劲的无人敢于问津的代码。XP让你不怎么怕它。你和你的同伴有很多测试用例保证你们不会在重构的时候破坏任何东西。

重构的目标是唯一的表达概念。Perl比其他语言更容易让你做到这个。ExtremePerl代码可以紧凑易懂，琅琅上口。这种代码经常演变成为我所称为的面向主题编程SMOP。

面向主题编程把问题浓缩到一种小的语句中。在这本书里面的SMOP用的是已经很成熟的Perl。没有必要另外发明一种新语法。有时候你得换个角度来考虑问题才能明白SMOP，除非你早就熟悉某种阐述式编程语言，它和我们在学校里面学习的命令式传统编程语言很不同。

你得很熟悉Perl才能读懂这些例子。我跳过Perl语法的细节直接解释例子。你得随时准备查阅好用的Perl参考手册，比如有时你得查看它才能明白map是怎么回事。

最后：有些测试用例是关于bivio在线业务处理平台（bOP）的。我所在公司（http://www.bivio.biz）开发的一个开源应用框架。如果你大量编写测试用例，可能需要工具来帮助你快速有效的编写。bOP用了SMOP来简化单元测试和用例测试。我不是要像你推销bOP（它是自由／免费的），只是要展示SMOP如何应用于测试。这本书为了解释例子而引入了刚好足够的bOP。

如何阅读本书

这本书向程序员和商人解释ExtremePerl。我还力图用（他人的）例子和个人经历为媒介来分享ExtremePerl的经验。这本书很详细的覆盖了极限编程的方方面面，所以即使以前没有经验也可以读懂。

本书的第一部分是ExtremePerl里面和编程无关的内容：why（背景），what（什么是极限编程和Perl）和how（发布计划，迭代计划，测试用例，跟踪和结对编程）。测试用例里面有些代码，但是任何人都应该能读懂。最后一章里面的SMOP是一个涉及到XP，Perl和SMOP的ExtremePerl例子。非编程人员可以扫过这章，重点阅读末尾的结论。

书的第二部分包含着众多真实的编程例子。随后的章节展示了什么是ExtremePerl：编码格调／规范，物流，测试驱动设计，延续式设计，单元测试，重构和SMOP。

若你是个自顶而下地考虑问题的人，我建议你从头到尾阅读本书。自底而上的读者可能最好反过来读。

如上一节所说，本书中的Perl代码可能比较难懂。每个编程的例子都不复杂，都只涉及为数不多的概念。然而代码对于有些程序员来说却可能显得非常复杂。如果你熟悉函数式编程和面向对象的Perl，这些例子就会变得一下子清晰起来。如果不是的话，你可能需要看看最后一章涉及到函数编程的部分。书中的参考资料也会很有用。面向对象的方面不怎么要紧，所以你哪怕没有面向对象的经验也可以明白。

词汇注释∶我会对XP和Perl社群中使用的术语做注解，但是我总是把它们展开使用所以你们也不用记住。

致谢

这本书是一个合作性的项目。很多人努力使这本书更好。任何错误和疏忽都是我的，而更正则来自于跟随的人。如果我在这里忘记了你的名子，请接受我的道歉。

给Joanne，谢谢你因为你用爱来支持我，也谢谢你的知识和积极的参与，以及编辑技巧。没你这本书就没辙。

给Ben和Aidan，谢谢你们因为你们如此快速的熟习XP。你们制作了上千张故事卡，还在生活中教我做人的道理。带孩子和学习XP总有些类似的地方。

给PaulMoeller，谢谢你因为你是一个如此卓越的商务伙伴，朋友和程序员。谢谢你教我为何编程不是一个体力活，还谢谢你对这本书的评价和保留在心里的感受。

给IonYadigaroglu，谢谢你的千言万语，你的支持和信任。还要谢谢你的勇气，是你把编程的活留给程序员来做.

给MartinLinchtin，谢谢你逐字逐句的解释为何indirection会带来新的软件问题，也感谢你这些年帮助我解决堆积如山的软件问题。

谢谢以下的人∶DannyAce，AnnalieseBeery，GregCompestine，EricDobbs，EricSchell，DavidFarber，JustinSchell和TomVilot。你们参与了我那疯狂的实验，耐心地听我的演讲和漫长的讨论，还有你教我关于编程，团队合作和兴趣培养的事。

谢谢JohannesRukkers，因为你教我在大机构里面如何编程，还有你在JamesJoyce那里的启发性的谈话，还有别处的谈话。

谢谢你RobWard，你优雅的放弃了在O&A使用真名的机会，还有你多年的耐心教导和支持我，另外你还严肃的指出本书草稿里面非理性和不成英语的部分。

谢谢StasBekman，JustinSchell和AledViggio，你们在最后一章和我结对编程。你们让我总是很快进入工作状态，还帮助我减少复杂性。

谢谢其他的很多审阅者，你们贡献了足够的反馈信息，这让我能写出更容易读懂也更加正确的代码。你们的名子按照字母顺序是∶JimBaker，KentBeck，TomBrown，DavidBruhweiler，SeanBurke，chromatic，PhilCooper，WardCunningham，BryanDollery，JeffHaemer，GedHaywood，JoeJohnston，WalterPienciak，ChrisPrather，LweisRowett，MichealSchwern，JeremySiegel和MikeStok。

我还得谢谢这些年来我的导师，他们是∶JonBondy，PeteBonham，DavidCheriton，TomLyon，JimMadden，RichardOlsen，AndrewSchofield和RogerSumner。你们的智慧都星星点点的散布在这本书里面，希望我都正确的掌握了它们。

最后，我还要对PeteBonham的家庭表示最深切的同情。你们让我在如此困难的时候走进你们的生活。Pete的离去是我写这本书的推动力，他一生的工作仍在引导我前进。

生命和工作是一系列的成功。它们每时每刻都在发生，XP只是让它更加易与显现，而你得选择去庆祝它们。

第一章

不管客户告诉你什么，那里基本上都是一个问题。—GeraldWeinberg

软件是一种稀有资源，供大于求。我们总是听说要满足需要得增加巨大数量的IT人才。有些人相信通过廉价开发外包可以提高产出。然而这只是把软件开发的问题转嫁给他人，而且这样做只不过增加了和客户无法沟通的程序员的数量，使得问题进一步恶化。

程序员的任务是准确的获得任务的细节。这不像在物质生产过程中，开销主要在于对流水线上每一个产品的复制上。外包对于生产来说很有效，因为细节都在设计阶段已经决定下来。生产过程主要是对已经决定的设计的重复。对于软件来说，拷贝的代价几乎没有，主要是设计阶段决定了产品的代价。便宜和充足的劳动力虽然提高了生产过程的效率，却无法用规模化生产给软件开发过程带来效率。

编程的代价是和网络效应相关的。在你给项目增加程序员数量的过程中，沟通的代价也随之以平方比率增长。因为项目中的细节必须在更多的渠道传播。而且随着客户和程序员之间的距离加大，重要渠道的数目也随着增加。减少客户和程序员之间的沟通代价是使细节得到有效实施的关键。这中间的等待时间会增加成本。为了提高效率，客户需要和程序员及时沟通，而程序员也需要得到客户的及时回应。

这一章区分软件开发和物质生产的不同之处。我们试图解释为什么传统的计划驱动的开发方法会增加项目的风险，为什么直面失败会减少风险。这一章以一个比喻来结束，它展示了需求和实现阶段的风险是如何通过让客户更接近开发过程来得到降低的。

一些统计数据

根据商业软件联盟的报道，软件产业正在以迅速的增长来满足看上去无限增长的需求。从1990年到1998年，美国的软件产业以每年13的速度增长。