邱志军 于2008年初

赛尔软件有限公司（筹）

敏捷开发（AD）是一种面临快速变化的需求快速软件开发的能力。获取敏捷性的三要素：

       人与人之间的交互是复杂的，并且其效果从来都难以预期，但却是工作中最为重要的方面。原则、模式、实践都很重要，但是使它们发挥作用的是人。人不是“插入即兼容的编程装置”，必须构建起有合作精神、自组织的团队。

失控的过程膨胀源于对项目失败的恐惧，在这种恐惧之下过程变得越来越庞大！！！

2001年敏捷联盟发布敏捷联盟宣言，声明其价值观和原则。宣言的具体内容如下：

个体和交互胜过过程和工具

可以工作的软件胜过面面俱到的文档

从上述价值观中引出下面12条原则，它们是敏捷实践区别于重型过程的特征所在。

我们最优先要做的是尽早的、持续的交付有价值的软件使客户满意

即使到了开发的后期，也欢迎改变需求

经常性的交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好

在整个项目开发期间，业务人员和开发人员必须天天都在一起工作

为了以敏捷的方式进行项目的开发，客户、开发人员和相关涉众之间必须进行有意义的、频繁的交互。

围绕被激励起来的个人来构建项目

团队中最有效果并富有效率的传递信息的方式，就是面对面的交谈

工作的软件是首要的进度度量标准

敏捷过程提倡可持续的开发速度

不断的关注优秀的技能和好的设计会增强敏捷能力

简单——使未完成的工作最大化的艺术——是根本的

最好的构架、需求和设计出自于自组织的团队

每隔一段时间，团队会反省如何更有效的工作

敏捷软件开发的原则和价值观构成了一个可以帮助团队打破过程膨胀循环的方法，这个方法关注的是可以达到团队目标的一些简单技术。已经有许多敏捷过程可供选择，包括：SCRUM、FDD、ADP以及XP。

作为开发人员，我们应该记住，极限编程并非唯一选择。

考虑能够工作的最简单的事情

只有在有证据，或有明显的迹象表明引入基础结构比继续等待合算时，才引入基础结构

极限编程是一组简单、具体的实践，这些实践组合在一起形成一个敏捷开发过程。

当你能够度量你所说的，并且能够用数字去表达它时，就表示你了解了它；若你不能度量它，不能用数字去表达它，那么说明你的知识是匮乏的，不能令人满意。

编写单元测试是一种验证行为，更是一种设计行为，更是一种编写文档的行为。此外，编写单元测试避免了相当数量的反馈循环，尤其是功能验证方面的反馈循环。

如果我们能够在设计程序前事先设计测试方案，情况会怎样？

如果我们能够做到：除非缺乏某个功能将导致测试失败，否则拒绝在程序中实现该功能，情况会怎么样？

如果我们能够做到：除非缺乏某行代码将导致测试失败，否则拒绝在程序中增加哪怕一行代码，情况会怎么样？

如果首先编写失败的测试以表明需要某项功能，然后再逐渐的增加哪项功能使测试通过，情况会怎么样？

测试驱动的开发方法带来的好处有：

一个测试优先设计的范例

按照便于我们阅读的方式编写测试，然后按照测试所暗示的结构去编写程序，这称为有意图的编程。在实现之前，现在测试中陈述你的意图，使你的意图尽可能简单、易读。

       在编写产品代码之前，先编写测试常常会暴露出程序中应该被解藕的区域。对类进行单元测试时，往往要同时测试与其协作的类，这时就需要隔离其协作类进行单独的测试。可以通过MOCK OBJECT模拟对象模式，在类及其协作者间插入接口，并创建实现这些接口的测试桩（TEST STUB）。

       作为验证工具来说，单元测试是必须的，但不够充分。单元测试用来验证系统的小的组成单元按照所期望的方式工作，但它没有验证系统作为一个整体的正确性。

我们应该以我们认为验收测试应该的样子去编写验收测试，然后构造脚本语言，并根据脚本语言的结构来构造系统。

大千世界中，唯一缺乏的就是人类的注意力。

Martin Fowler将重构定义为：在不改变代码外在行为的前提下对代码做出修改，以改进代码内部结构的过程。为什么要改变软件模块的内部结构呢？这要从软件模块的三项职责说起：

程序变得更易理解，因此也更易更改，且程序结构的各部分之间相互隔离，这也使它更易更改。重构就好比用餐后对厨房的清洁工作，重构的目的是每天清洁你的代码。

设计和编程都是人的活动，忘记这一点，将会失去一切。

       在敏捷团队中，全局视图和软件一起演化。在每次迭代时，团队改进系统设计，使设计尽可能适合于当前系统。

       设计中的臭味是一种症状，是可以主观进行度量的。这些臭味常常是出于违反了这些原则中的一个或多个而导致的，敏捷团队应用这些原则去除异味。

在按照我的理解方式审查了软件开发的生命周期后，我得出一个结论：实际上满足工程设计标准的唯一软件文档，就是源代码清单。

刚开始时，你能够获得系统的清晰视图，接着事情开始变遭，软件像一片坏面包一样开始腐化。最后，即使仅仅进行最简单的更改，也需要花费巨大的努力。管理人员开始强烈的要求进行重新设计，然而这样的重新设计很少成功。

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

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

       在非敏捷的环境中，由于需求没有按照初始设计预见的方式进行变化，从而导致设计的退化。然而，我们不能因为设计的退化而责怪需求的变化。我们必须设法找到一种方法，使得设计对于这种变化就有弹性，并且应用一些实践来防止设计腐化。

敏捷团队不允许软件腐化

       敏捷团队依靠变化获取活力。他们更愿意保持系统设计尽可能的简单、干净，并使用单元测试、验收测试做为支援。

敏捷开发人员知道要做什么，是因为：

软件开发的这三个方面的相互作用就是设计。

敏捷开发人员致力于保持设计尽可能的适当、干净。他们从来不说“稍后我们会回来修正他们”。设计必须要保持干净、简单，并且由于源代码是设计最重要的表示，所以它同样要保持干净。

敏捷设计是一个过程，不是一个事件，它是一个持续的应用原则、模式以及实践来改进软件的结构和可读性的过程。它致力于保持系统设计在任何时候都尽可能简单、干净以及富有表现力。

只有佛自己应当担负起公布玄妙秘密的职责。

单一职责原则，最初也被称为内聚性——一个模块的组成元素之间的功能相关性。

就一个类而言，应该仅有一个引起它变化的原因。每一个职责都是变化的一个轴线，当需求变化时，该变化会反映为类的职责的变化。如果一个类承担的职责过多，就等于把这些职责耦合在一起，这种耦合会导致脆弱的设计。通常对于单一职责的违反可能会导致一些严重的问题。

       在SRP中，我们把职责定义为变化的原因，如果你能够想到多于一个的动机去改变一个类，那么这个类就有了多于一个的职责。

       常常会有一些和硬件或者操作系统有关的原因，迫使我们把不愿耦合的东西耦合在一起。然而，对于其他部分来说，通过分离他们的接口我们已经解耦了概念。

持久化（违反SRP范例）

SRP是所以原则中最简单的，也是最难以正确应用的，实际上其余原则都是以这样或那样的方式回答SRP要解决的问题。

任何系统在其生命周期中都会发生变化，如果我们期望开发出的系统不会在第一版后就抛弃，尤其需要注意这一点。

开发——闭合原则（OCP）

软件实体应该是可以扩展的，但是不可以修改。如果程序中的一处改动就会产生连锁反应，那么设计就有僵化性的臭味，依旧OCP我们应当对代码进行重构。

遵循开闭原则设计的模块具有以下两种特征：

模块可以操作一个抽象体，由于模块依赖一个固定的抽象体，所以它对于更改可以是封闭的，通过从这个抽象类派生，也可以扩展此模块的行为。

Shape应用程序（略）

如果我们预测到这种抽变化，就可以设计一个抽象来隔离它。但是，这导致了一个麻烦的结果，一般而言，无论模块设计的多么封闭，都存在一些无法对之封闭的变化。这样我们就得预测变化的发生，并且一直等到变化发生时才采取行动。

       过去我们常常通过放置吊钩的方式预先隔离变化，然而放置吊钩常常是错误的。我们不希望背着许多不需要的抽象，直到真正需要时才放置进去。

l         只受一次愚弄：我们最初编写代码时，假设变化不会发生，当变化发生时，我们就创建抽象来隔离以后发生的同类变化

在许多方面，OCP都是面向对象设计的核心所在，遵循这个设计可以带来面向对象技术所声称的诸多好处。

OCP背后的主要机制是抽象和多态，在JAVA中这主要是通过继承来实现。但是，是什么设计规则支配着这种特殊继承用法呢？

对LSP可以做如下解释：子类型必须能够替换掉他们的基类型。

对于LSP的违反常常会导致以明显违反OCP的方式使用RTTI。

我们经常说继承是一个IS -A关系，这种关系有时会导致一些问题。如果新创建的派生类会导致改变基类，这常常意味着设计存在缺陷。

       LSP让我们得出一个非常重要的结论：一个模型，如果孤立的看，并不具有真正意义上的有效性。模型的有效性只能通过它的客户程序来体现，客户程序往往对模块作出一定的合理假设，有效性建立在对这种假设的预测之上。

从行为方式的角度来看，对象的行为方式才是软件真正所关注的问题。LSP清楚的指明，OOD中IS_A关系是关于行为的，行为方式是可以合理假设的，是客户程序所依赖的。

怎样才能知道客户的真正需求呢？有一项技术可以使这些合理的需求明确化——DBC基于契约的设计。使用DBC，类的编写者显式的规定对该类的契约，契约通过为每个方法声明前置条件和后置条件指定。按照Mayer所述，派生类的前置条件和后置条件规则是：在重写基类的方法时，只能使用相等或更弱的前置条件，只能使用相等或更强的后置条件。

OCP是OOD中许多说法的核心，LSP是是OCP成为可能的主要原则之一。

依赖倒置原则（DIP）

倒置，倒置的到底是什么呢？许多传统的软件开发方法，如面向结构的分析和设计，总是倾向于创建一些高层模块依赖底层模块、策略依赖于细节的软件结构。而一个面向对象的程序，其软件结构的依赖关系显然是倒置了。

高层模块包含了一个应用程序中重要的策略选择和业务模型，无论如何高层模块都不应该依赖底层模块，否则底层模块的改动势必影响高层模块。我们更希望重用的是高层的策略设置模块，DIP原则是框架设计的核心原则。

Booch曾经说过：所有结构良好的面向对象构架都具有清晰的层次定义，每个层都通过一个定义良好的、受控的接口向外提供一组内聚的服务。然而，对这句话理解不当的话，很容易就做出违反DIP原则的设计。其实，更为合理的设计应该是：每个较高层次都为它所需要的服务声明一个抽象接口，较低的层次实现了这些接口，每个高层类都通过抽象接口使用下一层，这样高层模块就不依赖底层模块。这样，倒置不仅是依赖关系的倒置，也是接口所有权的倒置，当应用DIP原则时，我们发现往往是他们的客户拥有抽象接口，而他们的服务者则从这些抽象接口派生。

       底层模块实现了在高层模块中声明的并被高层模块调用的抽象接口——这就是Hollywood原则。通过这种倒置的接口所有权，我们创建了一个更灵、更持久、更易改变的结构。

       依赖倒置的简单启发式规则：依赖于抽象，该规则建议不要依赖于具体类——也就是说程序中所有依赖关系都应终止于抽象类或接口。依据这个启发式规则，我们可以得出如下结论：

依赖倒置可以应用在任何存在一个类向另一个类发送消息的地方。违反DIP原则，高层策略自动依赖于底层模块，抽象就自动的依赖于具体细节。

什么是高层策略呢？它是应用背后的抽象，是那些不随具体细节改变而改变的真理，是系统内部的系统——隐喻。通常，遵循DIP原则的设计中的依赖只是名字上的概念，有时抽象的接口没有所有者，在JAVA中这样的接口一般放在单独的一个包中。

使用传统的过程化程序设计所创建的依赖关系结构，策略是依赖于细节的。面向对像的程序设计倒置了这种依赖。依赖倒置原则是实现面向对象技术承诺的好处的基本底层机制，对于创建可重用的框架是必须的。

接口隔离原则（ISP）

       接口隔离原则用来处理FAT接口的缺点，如果一个类的接口不是内聚的，就表示该类具有胖的接口。客户程序看到的应该是多个具有内聚接口的抽象基类。

在继承层次中解决接口依赖问题，往往会导致基类中的接口变胖——最终违反接口隔离原则。

既然客户程序是分离的，那么接口也应该保持分离。因为，客户程序对他们使用的接口有作用力。

客户对接口施加的反作用力

不应该强迫客户依赖于他们不用的方法，否则就容易导致所有客户程序间不必要的耦合。我们希望尽量避免这种耦合，因此我们希望分离接口。

一个对象的客户不是必须通过该对象的接口去访问它，也可以通过委托或对象的基类去访问它。

胖类会导致它们的客户程序之间产生不正常的并且有害的耦合关系。通过把胖类的接口分解为多个特定于客户程序的接口，这就解除了客户程序和他们没有用到的方法间的依赖关系，并使客户程序之间互不依赖。

没有人天生就有命令他人的权利。——Denis

       COMMAND模式是最简单、最优雅的模式之一，然而这种简单性具有欺骗性。COMMAND模式仅有带有一个方法的接口组成，该模式横过了一个非常有趣的界限。

       通过对命令概念的封装，该模式解除了系统的逻辑互联关系同实际连接的物理设备之间的耦合。

       通过创建和执行事务操作，解除了获取用户数据的代码、验证并操作数据的代码以及业务对象本省之间的耦合关系。

       通过创建事务对象，我们可以将事务置于一个列表中，以后在进行事务的相关处理，达到时间上解耦的目的。

如果Command派生类知道do方法可以知道它所执行的方法的细节，那么undo方法就可以取消这些操作，并把状态恢复到以前的状态。记住，这时do方法一般要保留一定的操作状态信息，以供undo方法使用。

模板方法和策略模式：继承和委托

继承关系蕴含的意义是非常深远的，使用继承我们可以基于差异编程。然而，继承非常容易被过度使用，并且过度使用的代价非常高。因此，我们推荐优先使用组合，而不是类继承。

本章介绍了模板方法模式和策略模式，他们解决的问题类似，不过模板方法模式使用继承解决问题，而策略模式使用的则是委托。