敏捷软件开发

出版时间：2003-09-01  出版社：清华大学出版社  作者：Robert C. Martin  页数：476  译者：邓辉  
Tag标签：无  

内容概要

在这本书中，享誉全球的软件开发专家和软件工程大师Robert C.Martin将向您展示如何解决软件开发人员、项目经理及软件项目领导们所面临的最棘手的问题。这本综合性、实用性的敏捷开发和极限编程方面的指南，是由敏捷开发的创始人之一所撰写的。
    ·讲述在预算和实践要求下，软件开发人员和项目经理如何使用敏捷开发完成项目；
    ·使用真实案例讲解如何用极限编程来设计、测试、重构和结对编程；
    ·包含了极具价值的可多次使用的C++和JAVA源代码；
    ·重点讲述了如何使用UML和设计模式解决面向客户系统的问题。

作者简介

Robert C.Martin是Object Mentor公司的总裁。Martin和他的软件咨询队伍使用面向对象设计、模式、UML、敏捷方法学和极限编程，在世界各地都有他们的客户。他还是好几本畅销书的作者。他还是1996-1999年《C++ Report》杂志的总编，并多次在国际会议和展览中发表富有特色的演讲。

书籍目录

第Ⅰ部分 敏捷开发 第一章 敏捷实践  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 设计的臭味——腐化软件的气味  7.3 “Copy”程序  7.4 保持尽可能好的设计  7.5 结论  参考文献 第八章 单一责任原则（SRP）  8.1 单一职责原则（SRP）  8.2 结论   参考文献 第九章 开放—封闭原则（OCP）  9.1 开放—封闭原则（OCP）  9.2 描述  9.3 关键是抽象  9.4 结论  参考文献 第十章 Liskov替换原则（LSP）  10.1 Liskov替换原则（LSP）  10.2 一个违反LSP的简单例子  10.3 正方形和矩形，更微妙的违规  10.4 一个实际的例子  10.5 用提取公共部分的方法代替继承  10.6 启发式规则和习惯用法  10.7 结论  参考文献 第十一章 依赖倒置原则（DIP）  11.1 依赖倒置原则（DIP）  11.2 层次化  11.3 一个简单的例子  11.4 熔炉示例  11.5 结论  参考文献  第十二章 接口隔离原则（ISP）  12.1 接口污染  12.2 分离客户就是分离接口  12.3 接口隔离原则（ISP）  12.4 类接口与对象接口  12.5 ATM用户界面的例子  12.6 结论  参考文献第Ⅲ部分  薪水支付案例研究 第十三章 COMMAND模式和ACTIVE OBJECT模式 第十四章 TEMPLATE METHOD模式和STRATEGY模式：继承与委托 第十五章 FACADE模式和MEDIATOR模式 第十六章 SINGLETON模式和MONOSTATE模式 第十七章 NULL OBJECT模式 第十八章 薪水支付案例研究：第一次迭代开始 第十九章 薪水支付案例研究：实现第Ⅳ部分 打包薪水支付系统 第二十章 包的设计原则 第二十一章 FACTORY模式 第二十二章 薪水支付案例研究（第2部分）第Ⅴ部分 气象站案例研究 第二十三章 COMPOSITE模式 第二十四章 OBSERVER模式——回归为模式 第二十五章 ABSTRACT SERVER模式、ADAPTER模式和BRIDGE模式 第二十六章 PROXY模式和STAIRWAY TO HEAVEN模式：管理第三方API 第二十七章 案例研究：气象站第Ⅵ部分 ETS案例研究 第二十八章 VISITOR模式 第二十九章 STATE模式 第三十章 ETS框架附录            附录A UML表示法Ⅰ：CGI示例 附录B UML表示法Ⅱ：统计多路复用器 附录C 两个公司的讽刺小品 附录D 源代码就是设计 索引

章节摘录

　　7.2 设计的臭味——腐化软件的气味　　当软件出现下面任何一种气味时，就表明软件正在腐化。　　僵化性（Rigidity）：很难对系统进行改动，因为每个改动都会迫使许多对系统其他部分的其他改动。　　脆弱性（Fragility）：对系统的改动会导致系统中和改动的地方在概念上无关的许多地方出现问题。　　牢固性（Immobility）：很难解开系统的纠结，使之成为一些可在其他系统中重用的组件。　　粘滞性（Viscosity）：做正确的事情比做错误的事情要困难。　　不必要的复杂性（Needless Complexity）：设计中包含有不具任何直接好处的基础结构。　　不必要的重复（Needless Repetition）：设计中包含有重复的结构，而该重复的结构本可以使用单一的抽象进行统一　　。晦涩性（Opacity）：很难阅读、理解。没有很好地表现出意图。　　1.僵化性　　僵化性是指难以对软件进行改动，即使是简单的改动。如果单一的改动会导致有依赖关系的模块中的连锁改动，那么设计就是僵化的。必须要改动的模块越多，设计就越僵化。　　大部分的开发人员都以这样或者那样的方式遇到过这种情况。他们会被要求进行一个看起来简单的改动。他们看了看这个改动并对所需的工作做出了一个合理的估算。但是过了一会儿，当他们实际进行改动时，会发现有许多改动带来的影响自己并没有预测到。他们发现自己要在庞大的代码中搜寻这个变动，并且要更改的模块数目也远远超出最初估算。最后，改动所花费的时间要远比初始估算长。当问他们为何估算得如此不准确时，他们会重复软件开发人员惯用的悲叹，“它比我想像的要复杂得多！”　　2.脆弱性　　脆弱性是指，在进行一个改动时，程序的许多地方就可能出现问题。常常是，出现新问题的地方与改动的地方并没有概念上的关联。要修正这些问题就又会引出更多的问题，从而使开发团队就像一只不停追逐自己尾巴的狗一样（忙得团团转）。　　随着模块脆弱性的增加，改动会引出意想不到的问题的可能性就越来越大。这看起来很荒谬，但是这样的模块是非常常见的。这些模块需要不断地修补——它们从来不会被从错误列表中去掉，开发人员知道需要对它们进行重新设计（但是谁都不愿意去面对重新设计中的难以琢磨性），你越是修正它们，它们就变得越糟。　　3.牢固性　　牢固性是指，设计中包含了对其他系统有用的部分，但是要把这些部分从系统中分离出来所需要的努力和风险是巨大的。这是一件令人遗憾的事，但却是非常常见的事情。　　4.粘滞性　　粘滞性有两种表现形式：软件的粘滞性和环境的粘滞性。　　当面临一个改动时，开发人员常常发现会有多种改动的方法。其中，一些方法会保持设计；而另外一些会破坏设计（也就是生硬的手法）。当那些可以保持系统设计的方法比那些生硬手法更难应用时，就表明设计具有高的粘滞性。做错误的事情是容易的，但是做正确的事情却很难。我们希望在软件设计中，可以容易地进行那些保持设计的变动。　　……

媒体关注与评论

书评第13届软件开发震撼大奖获奖作品；国际软件工程和开发大师最新力作；众多名家一致推荐的敏捷开发指南；软件工程发展史上的里程碑性巨著。希望你能喜爱这本书。希望你能像我一样学着以创建美的软件而骄傲，并享受其中的快乐。如果你从本书中略微看到了这种快乐，如果本书使你感受到了这种骄傲，如果本书点燃了你内心欣赏这种美的火花，那么就远超过我的目标了。

用户评论 (总计23条)

•   书是好书，也很仔细地读。只是读到347页的时候，之后一直到363页都是印错的。在28 visitor这一章，胡乱地将29章和30章的一部分穿插在这里，很让人失望。不知道这种情况卓越如何处理？
•   下面那位朋友说的差点就让我错过了这本巨好无比的书，这本书的讲解方式比较特别，不是只讲什么什么模式干什么，都是先给出一个问题，然后给出一个解决问题的实现方案，然后讨论该方案有什么缺点，再从缺点推导出应该使用的模式。非常非常好的一本书，建议与<<设计模式解析(第2版)>>一起看！感谢作者为我们写出这么好的书！
•   这是一本非常好的书，翻译也相当给力。本人4年码农，在工作中常有自己的思路和困惑，这本书提到的一些方法非常富有启发意义。
•   有时间有精力的话，不妨买一本看看。[...] 敏捷无敌,网上最大的敏捷软件开发资料站
•   内容比较精彩,讲的也比较通俗易懂
•   不愧是经典，没啥好说的...
•   对于一个初学者来说 过于深奥了 不过 应该是好书 呵呵
•   纸张有点薄，力透纸背的感觉！
•   书的内容非常好希望对自己接下来应聘有帮助
•   可以作为经典教材收藏
•   经典，很好的一本软件设计书籍
•   绝对值，但是只是内容。书的质量也还不错。
•   刚看了看前言还没怎么看呢
•   书本质量还不错、发货也比较快。。。读书吧 骚年们
•   很经典的一本书，书的质量也很好，第二天就到了
•   速度快，质量好，很满意。
•   书还是给力的
•   正在看呢，书的质量还是不错的
•   偏重模式设计
•   不错，多块好省~~~~~~~~~~~
•   坚持多读书，开卷有益
•   软件开发用书
•   敏捷软件开发