第Ⅰ部分 敏捷开发 第一章 敏捷实践 1.1 敏捷联盟 1.2 原则 1.3 结论 参考文献 第二章 极限编程概述 2.1 极限编程实践 2.2 结论 参考文献 第三章 计划 3.1 初始探索 3.2 发布计划 3.3 迭代计划 3.4 任务计划 3.5 迭代 3.6 结论 参考文献 第四章 测试 4.1 测试驱动的开发方法 4.2 验收测试 4.3 结论 参考文献 第五章 重构 5.1 素数产生程序一个简单的重构示例 5.2 结论 参考文献 第六章 一次编程实践 6.1 保龄球比赛 6.2 结论 第Ⅱ部分 敏捷设计 第七章 什么是敏捷设计 7.1 软件出了什么错 7.2 设计的臭味——腐化软
软件工程实践丛书 敏捷软件开发 原则、模式与实践 (美) Robert c. Martin著 群译 孟岩审 清华大学出版社 北京 内容銜介 沜仝球旳欤件开发专家和软件¨栏大帅 Robert, martir向您介绍妇何解决软件开发人员、目 纶及軟廾頃口领导们所临的棘的问題,这综合性、实用少的敏捷开发和极編程方而的指 南,讲述了在须算利时间要求下软件奸发人员和项订经理如何使用饿优开发完成项目;使A真实茉例 讲解如们极限編来设讦、测试、重构和结刈编程;包含了极具价值的可重用的C++和」ava顓代鸦; 还重点讲述了如何使用UML和设训模式解决血问尸系统的阿题、 本书」2003年菜获第13妯软件开发图书震憾大奖,适于用作高校计算机专业本料生、研究生和 钦件学院的软「程和软件开关课稈的教树或参若书,也涵于软件开发和管理人提高作身水平 用 Simplified Chinese edition copyright 2003 by PEARSON EDUCATION ASIA LIMITED and TSINGHUA UNIVERSITY PRESS Original English language title from Proprietor's edition of the Work Original English language title: Agile Software Development Principles, Pattens, and Practices, 1st Edition by Robert C Martin, Copyright 2003 E|SBN:013597444-5 All Rights reserved Published by arrangement with the original publisher, Pearson Education, Inc. publ shing as Pearson education Inc This edition is authorized for sale only in the People's Republic of China(excluding thc spccial Adminlstrative Reglon of Hong Kong and Macao 小书中文简体译版由 Pearson educaton授权终清华大学出版社中巾国境内(不包插中医香、 澳门犊别行政区)山版发行 北桌版局苦作权合同脊记号图:01-2002-5761 本书封面贴有 Pearson education培生教育出版集团)激光防伪标签.无标签者不得销售 图书在版编目(CP)数据 捷欤件开发:原则、模式与实政/(美)马」著:邓辉译,孟岁审.一北京:清伴大学出版社,2003 软件1科实战从书 19名原义: Agile Software Developrment: Principles, athens, and Practices ISBN7320197-7 .敏…Ⅱ.当…园艰…③孟…Ⅲ.软件斤发!V."P31.52 中版本图「馆CP数据梭字(2003)第0273号 出版者:清华大学出叔社 地址;北京潸华人学学研k厦 邮编 社总机;010-6277( 客户服务:1062776959 文楠编辑:尤晓东 封面设计:付剑飞 印刷者:北京国马印刷厂 发行者:新华书店总北京发行所 开本:185×260印张:31.25插页:2字鲨:942千字 版次:203年9月第1版203年9月第1次耳刷 书号:ISEN7-302-71977;TP·5239 印数:1 定价:59.0元 敏捷软件开发宣言 我们正在通过亲身实践以及帮助他人实践,揭示 更好的软件开发方法。通过这项工作,我们认为 个体和交互 胜过过程和工具 可以工作的软件胜过面面俱到的文档 客户合作 胜过合同谈判 晌应变化 胜过遵循计划 虽然右项也具有价值, 但我们认为左项具有更大的价值。 Kent beck ames Grenning Robert c martin Mike beedle Jim Highsmith Sieve mellor Arie van bennekum Andrew hunt Ken schwaber Alistair Cockburn Ron jeffries Jeff Sutherland Ward Cunningham Jon Kern Dave thomas Martin Fowler Brian marick 敏捷宣言遵循的原则 我们遵循以下原则 我们最优先要放的是通过尽早的、持续的交付有价值的软 件来使客户满意 即使到了开发的后期,也欢迎改变需求。敏捷过程利用变 化来为客户创造竞争优势 经常性地交付可以工作的软件,交付的间隔可以从几个星 期到几个月,交付的时间问隔越短越好 在整个项目开发期间,业务人员和开发人员必须天天都在 趣工作 围绕被激励起来的个体来枃建项目。给他们提供所需的环 境和支持,并且信任他们能够完成工作。 在团队内部,最具有效果并目富有效率的传递信息的方 法,就是面对面的交谈 工作的软件是首要的进庋度量标准。 敏捷讨程提倡可持续的开发速度。责任人、开发者和用户 应该能够保持一个长期的、恒定的开发速度 不断地关注优秀的技能和好的设计会增强敏捷能力 简单—使来完成的工作最大化的艺术—是根本的 最好的构架、需求和设计出自于自组织的团队。 每隔一定时间,团队会在如何才能更有效地工作方面进行 反省,然后相应地对自己的行为进行调整 面向对象设计的原则 SRP单一职责原则 就一个类而言,应该仅有一个引起它变化的原因 OCP开放一封闭原则 软件实体(英、模块、函数)应该是可以扩展的,但是不可修改。 LSP LiskoⅤ替换原则 子类型必须能够替换掉它们的基类型 DP依赖倒置原则 抽象不应该佼赖于细节。细节应该依赖于抽象. SP接囗隔离原则 不应该强迫容户依赖于它们不用的方法。接口属于客户,不属于它 所在的类层次结构。 REP重用发布等价原则 重用的粒度就是发冇的粒度。 CCP共同封闭原则 包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化 若对-个包产生影响,则将对该包中的所有类产生影响,而对于其 他的包不造成任何影响。 CRP共同重用原则 个包中的所有类应该是共同重用的。如果重用了包中的一个类 那么就要重用包中的所有类 ADP无环依赖原则 在包的依赖关系图中不允许存在环 sDP稳定依赖原则 朝着稳定的方向进行依赖 sAP稳定抽象原则 包的拈象桪度应该和其稳定程度一致。 极限编程实践 完整团队 XP硕目的所有参与者(开发人员、业务介析师、测试人員等等)-赵工作在-个开 放的场所中,他们是冏一饣团队的成贞。这个场所的漕壁随意悬挫着大幅的、显著的彐 表以及其他一些显示他们进度的东西 计划游戏 计划是持续的、循序渐进的。每2周,开发人员就为τ2月估算候选特性的成本,而 容户则祁据成本和商务价值来选择要实现的特性」 客户测试 作为选择毎个所期望的特性的一部分,客户定义出自动验收测武来表明该特性可以工 简单设计 闭队保持设计恰好和当前的系铳功能扫匹憇,它通过了所有的测试,不包含任何重复 表达出了编写者想表达的所有东西:并阻包含尽可能少的代码, 结对编程 所有的产品软仲都是由两个程序员、并排坐在一起在同一台机器上姁建的。 测试驱动开发 程序员以非常短的循坏周工作,他们先增加一个失的测试、然后使之通过 改进设计 随时改进糟糕的代码。保持代鸸尽可能竹一净、具有表达力 持续集成 团队总是使系统完整地被集成。 集体代码所有权 任何结对的程序员都可以在任何时候改进任何代码 编码标准 系统中所有的代码看起来就好像是被单独一个一一非常鱼得胜任的一一人编写的 隐喻 团队提出一个程序工作原理的公共景像 可持续的速度 团队只有持久才有胜的布望.他们以能够长期绝持的速度努力上作,他们保存婿力 他们把项目看作是马拄松长跑,而不是全速短跑 中文版序:软件之美 除了我的家庭,软件是我的挚爱。通过它,我可以包造出美的东西。软件之美在于它的功能, 在于它的内郭结构,还在于团队创它的过程。对用户来说,通过直观、简单的界面早现出怡当悖 性的程序就是美的。对软件设计者来说,被简单、自地分割,并具有最小内部耦合的内部结构就 是关的。对开发人员和管理者来说,每周都会取得重大进展,并且生产出无缺陷代妈的貝有活力的 团队就是美的。美存在于所有这些层次之中,它们都是本书容的一部分 软作开发人员如何学到创造美的知识呢?在本书中,我讲梫了一些原则、模式以及实践,它们 可以帮助软件开发人员祚追求美的程序、设计以及团队的道路上迈出第-步。其中,我们探素了基 本的设计原刘,软件设计结构的通用模式以及有助于团队融为一个有机整体的一系列实践。由于本 丨是关于软件订发的,所以包含了许多代码。伃细研究这些代码是学习本书所教授的原则、模式以 攴实践的最有效方法 人们需要软件——需要许多的软件。50年前,软件还只是运行在少量大型、昂的机器之上。 30了,软卅可以运打在大多数公司和T业坏境之中。现在,移动电话、手表、电器、汽车、玩具 以及工具中都运行有软件,并且对更新、更好软作的需求永远不会停止。随着人类文明的发展和壮 大,随着发展中国家不眯构建它们的基础设施,随着发达国家努力追求更高的效率,就需要越来越 多的软件。如果在所有这些软件之中,都没有美存在,这将会是一个很大的遗憾 我知道软件可能会是丑陋的。我们知道软件可能会难以使用、不可靠并且是粗制滥造的;我 们知道有一些软竹系统,其混轧、粗的内部给构使得对它们的更改既昂贵又困难:我们还见过那 些通过笨拙、难以使用的界面展现其特性的软系统;我们同样也见过那些易崩溃且行为不当的软 件系统,这些都是晒的系统。糟糕的是,作为一种职业,软件开发人员所创建出来的美的东西却 往往少于丑的东西。如果你正在阅读这本书,那么你也许就是那个想去创造美不是丑的人。 最好的软件开发人员都知道个秘密:关的东比的尔死创建起来更廉价,也更快婕。构建、 维护一个芙的软件系統所花费的时、金钱都要少于丑的系统。软件开发新手往往不理解这点 他们认为傚每件事情都必须要快,他们认为美是不实用的ε错!由于事情做得快,他们造成的混 乱致使软件僵化,难以理解。美的系统是灵活、易于理解的,构建、维护它们就是一种快乐。丑兩 的系统才是不实用的。H陋会降低你的开发速度,使你的件昂贵又脆弱。构建、维护美蚋系统 所花责的代价最少,交付起来也最快 我希望你能喜爱这本书。我希望你能像我一样学着以创建美的软件而骄傲,并—受其中的快乐。 如果你从六书中略黴看到了这种快乐,如果本书使你开始感受到∫这种骄傲,如果本弓点燃了你内 欣赏这种关的火花,那么就远超过我的目栎∫。 C ME 2003年8月2]日 The Beauty of software RObert C. Martin's foreword for Agile Software Development Chinese Version Next to my family, software is my passion. It is a medium in which I try ta create beauty. The beauty a sofware is in iI's function, in it's intemal structure, and in the way in which it is created by a team. to a user, a program with just the right fcaturcs prcscntcd thrcugh an intuitive and simple interface, is beautiful To a software designer, an intemal structure that is partitioned in a simple and intuitive manner, and that minimizes internal coupling, is beautiful. To developers and managers, a motivated team of develpers all these levels, and they are all part of the topic of this bar Cct-free code, is beautiful. There is beauty on making significant progress every week, and producing defer How do software developers learn how to create this beauty? in this book I teach the principles, pattcrmg and practices that can help software developers take the first steps towards beautiful programs, designs and teams. In these pages we explore basic design principle, cormon patterns inn the structure of a software design, and a set of practices that can help a tean knit itself into a functioning whole. Since this book is about software development, it contains a lat of code. The principles, pattems, and practices that this book teaches are learned most effectively by carefully studying that code, Our world needs software -- lots of software. Fifty years ago software was something that ran in a few big and expensive machines. Thirty years ago it was something that ran in most companies and industrial settings. Now there is software running in our cell phones, watches, appliances, automobiles, toys, and tools. And need for new and better software never stops, As our civilization grows and expands,as devcloping nations build thcir infrastructures, as dcvclopcd nations strive to achieve cvcr greater efficiencies, the need for more and more software continues to increase. It would be a great shame if, in all that software, there was no beauty We: know thAt. software can he ugly. We know that it can he hard to use, unreliable, and carelessly structured. We know that there are software systems whose tangled and careless internal structures make them expensivc and difficult to change. We know that there arc softwarc syatcma that prcscnt thcir features through an awkward and cumbersome interface. We know that there are software systems that crash and mishehave. These are ugly system. Unfortunately, as a profession, software developers tend to create more ugly systems than beautiful ones. If you are reading this book, then you are someone who wants to crcatc beauty and not ugliness There is a sccrct that the best software developers kmow. Beauty is cheaper than ugliness. Beauty is faster than ugliness. A beautiful software system can be built and maintained in less time, and for less money, than an ugly one. Novice software developers don't understand this. They think that they have to do everything last and quick. They think that beauty is impractical. No! By doing things East and quick, they make messes that make the software stiff, and hard to understand, Beautiful systems are flexible and easy to understand. Building thom and maintaining them is a joy. It is ugliness that impractical. Ugliness will slow you down and make your sofiware expensive and brittle. beautifu systems cost the least to build and maintain and are delivered soonest I hope you cnjoy this book. I hope you learn to takc as much pride and joy in thc creation of beautiful software that I do. If this book can show you just an inkling of that joy, motivate you to feel just the beginnings of that pride, and provide just a spark of appreciation for that beauty, then it has more than accomplished my goal for it