敏捷软件开发 原则、模式与实践pdf

敏捷软件开发 原则、模式与实践 内容简介

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

敏捷软件开发 原则、模式与实践 目录

第Ⅰ部分 敏捷开发

第一章 敏捷实践

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.粘滞性

粘滞性有两种表现形式：软件的粘滞性和环境的粘滞性。

当面临一个改动时，开发人员常常发现会有多种改动的方法。其中，一些方法会保持设计；而另外一些会破坏设计（也就是生硬的手法）。当那些可以保持系统设计的方法比那些生硬手法更难应用时，就表明设计具有高的粘滞性。做错误的事情是容易的，但是做正确的事情却很难。我们希望在软件设计中，可以容易地进行那些保持设计的变动。