　　《敏捷软件开发：原则模式与实践》是综合性、实用性的敏捷开发和极限编程方面的指南，讲述了在预算和时间要求下软件开发人员和项目经理如何使用敏捷开发完成项目：使用真实案例讲解如何用极限编程来设计、测试、重构和结对编程；包含了极具价值的可重用的C++和Java源代码；还重点讲述了如何使用UML和设计模式解决面向客户系统的问题。《敏捷软件开发：原则模式与实践》于2003年荣获第13届软件开发图书震撼大奖，适于用作高校计算机专业本科生、研究生和软件学院的软件工程和软件开发相关课程的教材或参考书，也适于软件开发和管理人员提高自身水平学习之用。

内容简介

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

作者简介

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

精彩书评

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

第Ⅰ部分敏捷开发
第一章敏捷实践
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.粘滞性
粘滞性有两种表现形式：软件的粘滞性和环境的粘滞性。
当面临一个改动时，开发人员常常发现会有多种改动的方法。其中，一些方法会保持设计；而另外一些会破坏设计（也就是生硬的手法）。当那些可以保持系统设计的方法比那些生硬手法更难应用时，就表明设计具有高的粘滞性。做错误的事情是容易的，但是做正确的事情却很难。我们希望在软件设计中，可以容易地进行那些保持设计的变动。
……