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

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

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

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

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

7.2 设计的臭味——腐化软件的气味

当软件出现下面任何一种气味时，就表明软件正在腐化。

僵化性（Rigidity）：很难对系统进行改动，因为每个改动都会迫使许多对系统其他部分的其他改动。

脆弱性（Fragility）：对系统的改动会导致系统中和改动的地方在概念上无关的许多地方出现问题。

牢固性（Immobility）：很难解开系统的纠结，使之成为一些可在其他系统中重用的组件。

粘滞性（Viscosity）：做正确的事情比做错误的事情要困难。

不必要的复杂性（Needless Complexity）：设计中包含有不具任何直接好处的基础结构。

不必要的重复（Needless Repetition）：设计中包含有重复的结构，而该重复的结构本可以使用单一的抽象进行统一

。晦涩性（Opacity）：很难阅读、理解。没有很好地表现出意图。

1.僵化性

僵化性是指难以对软件进行改动，即使是简单的改动。如果单一的改动会导致有依赖关系的模块中的连锁改动，那么设计就是僵化的。必须要改动的模块越多，设计就越僵化。

大部分的开发人员都以这样或者那样的方式遇到过这种情况。他们会被要求进行一个看起来简单的改动。他们看了看这个改动并对所需的工作做出了一个合理的估算。但是过了一会儿，当他们实际进行改动时，会发现有许多改动带来的影响自己并没有预测到。他们发现自己要在庞大的代码中搜寻这个变动，并且要更改的模块数目也远远超出最初估算。最后，改动所花费的时间要远比初始估算长。当问他们为何估算得如此不准确时，他们会重复软件开发人员惯用的悲叹，“它比我想像的要复杂得多！”

2.脆弱性

脆弱性是指，在进行一个改动时，程序的许多地方就可能出现问题。常常是，出现新问题的地方与改动的地方并没有概念上的关联。要修正这些问题就又会引出更多的问题，从而使开发团队就像一只不停追逐自己尾巴的狗一样（忙得团团转）。

随着模块脆弱性的增加，改动会引出意想不到的问题的可能性就越来越大。这看起来很荒谬，但是这样的模块是非常常见的。这些模块需要不断地修补——它们从来不会被从错误列表中去掉，开发人员知道需要对它们进行重新设计（但是谁都不愿意去面对重新设计中的难以琢磨性），你越是修正它们，它们就变得越糟。

3.牢固性

牢固性是指，设计中包含了对其他系统有用的部分，但是要把这些部分从系统中分离出来所需要的努力和风险是巨大的。这是一件令人遗憾的事，但却是非常常见的事情。

4.粘滞性

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

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

　　敏捷开发（Agile Development）是一种面临迅速变化的需求快速开发软件的能力。为了获取这种敏捷性，我们需要使用一些可以提供必要的纪律和反馈的实践。我们需要使用一些可以保持我们的软件灵活、可维护的设计原则，并且我们需要知道一些已经被证明针对特定的问题可以平衡这些原则的设计模式。本书试图把所有这3个概念编织在一起，使它们成为一个有机的整体。
　　本书首先描述了这些原则、模式以及实践，然后通过学习许多的案例来演示是如何应用它们的。更重要的是，研究案例介绍的并不是最终已完成的结果，而是设计的历程。你会看到设计者犯错误；你会看到他们是如何识别出错误并最终改正错误；你会看到他们对于难题的苦苦思索以及对于一些权衡和含糊问题的苦恼；你会看到设计的行为。隐藏在细节之中
　　本书包含有许多的Java和CH代码。我希望你能够仔细地学习这些代码，因为在很大程度上，代码正是本书的要旨。代码就是本书要讲的内容的实现。
　　本书采用了一种重复的讲解方式。它由一系列不同规模的案例研究组成。有一些非常的小，有一些却需要用几章来描述。每个案例研究之前都有一些针对该案例研究的预备内容。例如，在薪水支付案例研究之前，就有一些描述在该案例研究中用到的面向对象设计原则和模式的章节。
　　本书首先对开发实践和过程进行了讨论，其中穿插了许多小的案例研究以及示例。从这些穿插点处，本书转移到设计和设计原则的主题上，接着是一些设计模式、更多的管理包的设计原则以及更多的模式。所有这些主题都附有案例研究。
　　因此，请准备好学习一些代码并钻研一些UML（统一建模语言）图。你将要学习的书籍是非常技术性的，并且其中要教授的知识和恶魔一样，也隐藏在细节之中。
　　一段小史
　　大约6年前，我写了一本名为：Designing Object Oriented C++ Application using the Booch Method的书。它是我的一部主要作品，并且它的效果和销量都令我非常满意。
　　本书开始时是被作为Designing 一书的第2版的，但是结果却并非如此。在本书中所保留的原书中的内容是非常少的。只有3章的被维持下来，并且对这些章节进行了重大的修改。书的意图、精神以及许多的知识是相同的。但是，自Desinging出版6年以来，在软件设计方面我又学到了非常多的知识。
　　本书表现了这些知识。
　　几年过去了！Designing刚好在Internet爆炸式流行之前出版。从那时起，我们要面临的缩略词的数量已经翻了一倍，诸如：Design Pattems、Java、EJB、RMI、J2EE、XML、XSLT、HTML、ASP、JSP、Servlets、Application Servers、ZOPE、SOAP、C#、.NET等等。我要告诉你，使本书的内容跟得上最新的技术知识是很困难的。
　　与Booch的合作
　　1997年，Booch和我联系，让我帮他撰写他的非常成功Object-Oriented Analysis and Design withApplications 一书的第3版。以前，我和Grady在一些项目中有过合作，并且我是他的许多作品（包括UML）的热心读者和参与者。因此，我高兴地接受了。我邀请了我的好朋友Jim Newkirk来帮助完成这项工作。
　　在接下来的2年中，我和Jim为Booch的书撰写了许多的章节。当然，这些成果意味着我不可能在这本书中按照我本来想的那样投入同样多的努力，但是我觉得Booch的书值得我这样做。另外，当时本书完全只是Designing的第2版，并且我的心思也不在其上。如果我要说一些东西的话，我想说一些新的并且不同的东西。
　　糟糕的是，Booch的这个版本的书并没有完成。在正常的时间里很难抽出空来撰写一本书。在浮躁的“.com”泡沫期间，这几乎是不可能的。Grady也更加忙于Rational以及一些像Capapulse这样的新风险投资企业的事务。因此这项工作就停止了。最后，我问Grady和Addison-Wesley是否可以把我和Jim撰写的那些章节包含在这本书中。他们很有风度地同意了。于是，一些案例研究和UML的章节就从此而来。极限编程的影响
　　1998年晚期，XP崭露头角，并向我们所珍爱的关于软件开发的观念进行挑战。我们是应该在编写任何代码前先创建许多UML图呢？还是应该避开任何种类的UML图而仅仅编写大量代码呢？我们是应该编写大量的描述我们设计的叙述性文档呢？还是应该努力使代码具有自释义能力以及表达力，这样辅助性的文档就不再必要了呢？我们应该结对编程吗？我们应该在编写产品代码前先编写测试吗？我们应该做什么呢？