敏捷开发

敏捷开发
　　人与人之间的交互是复杂的，并且其效果从来都是难以预期的，但却是工作中最重要的方面。

-- Tom DeMacro和Timothy Lister

敏捷软件开发宣言：

• 个体和交互     胜过 过程和工具
• 可以工作的软件 胜过 面面俱到的文档
• 客户合作       胜过 合同谈判
• 响应变化       胜过 遵循计划

虽然右项也有价值，但是我们认为左项具有更大的价值。

• 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
• 即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
• 经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。
• 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
• 围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。
• 在团队内部，最具有效果并富有效率的传递信息的方法，就是面对面的交谈。
• 工作的软件是首要的进度度量标准。
• 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
• 不断地关注优秀的技能和好的设计会增强敏捷能力。
• 简单是最根本的。
• 最好的构架、需求和设计出于自组织团队。
• 每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。

当软件开发需求的变化而变化时，软件设计会出现坏味道，当软件中出现下面任何一种气味时，表明软件正在腐化。

• 僵化性： 很难对系统进行改动，因为每个改动都会迫使许多对系统其他部分的其它改动。
• 脆弱性： 对系统的改动会导致系统中和改动的地方在概念上无关的许多地方出现问题。
• 牢固性： 很难解开系统的纠结，使之成为一些可在其他系统中重用的组件。
• 粘滞性： 做正确的事情比做错误的事情要困难。
• 不必要的复杂性： 设计中包含有不具任何直接好处的基础结构。
• 不必要的重复性： 设计中包含有重复的结构，而该重复的结构本可以使用单一的抽象进行统一。
• 晦涩性： 很难阅读、理解。没有很好地表现出意图。

敏捷团队依靠变化来获取活力。团队几乎不进行预先设计，因此，不需要一个成熟的初始设计。他们更愿意保持设计尽可能的干净、简单，并使用许多单元测试和验收测试作为支援。这保持了设计的灵活性、易于理解性。团队利用这种灵活性，持续地改进设计，以便于每次迭代结束生成的系统都具有最适合于那次迭代中需求的设计。为了改变上面软件设计中的腐化味，敏捷开发采取了以下面向对象的设计原则来加以避免，这些原则如下：

• 单一职责原则(SRP)
  就一个类而言，应该仅有一个引起它变化的原因。
• 开放-封闭原则(OCP)
  软件实体应该是可以扩展的，但是不可修改。
• Liskov替换原则(LSP)
  子类型必须能够替换掉它们的基类型。
• 依赖倒置原则(DIP)
  抽象不应该依赖于细节。细节应该依赖于抽象。
• 接口隔离原则(ISP)
  不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的类层次结构。
• 重用发布等价原则(REP)
  重用的粒度就是发布的粒度。
• 共同封闭原则(CCP)
  包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包产生影响，则将对该包中的所有类产生影响，而对于其他的包不造成任何影响。
• 共同重用原则(CRP)
  一个包中的所有类应该是共同重用的。如果重用了包中的一个类，那么就要重用包中的所有类。
• 无环依赖原则(ADP)
  在包的依赖关系图中不允许存在环。
• 稳定依赖原则(SDP)
  朝着稳定的方向进行依赖。
• 稳定抽象原则(SAP)
  包的抽象程度应该和其稳定程度一致。

　　上述中的包的概念是：包可以用作包容一组类的容器，通过把类组织成包，我们可以在更高层次的抽象上来理解设计，我们也可以通过包来管理软件的开发和发布。目的就是根据一些原则对应用程序中的类进行划分，然后把那些划分后的类分配到包中。

下面举一个简单的设计问题方面的模式与原则应用的示例：

问题：
　　选择设计运行在简易台灯中的软件，台灯由一个开关和一盏灯组成。你可以询问开关开着还是关着，也可以让灯打开或关闭。

解决方案一：
　　下面图1是一种最简单的解决方案，Switch对象可以轮询真实开关的状态，并且可以发送相应的turnOn和turnOff消息给Light。


解决方案二：
　　上面这个设计违反了两个设计原则：依赖倒置原则(DIP)和开放封闭原则(OCP)，DIP原则告诉我们要优先依赖于抽象类，而Switch依赖了具体类Light，对OCP的违反是在任何需要Switch的地方都要带上Light，这样就不能容易扩展Switch去管理除Light外的其他对象。为了解决这个方案，可以采用ABSTRACT SERVER模式，在Switch和Light之间引入一个接口，这样就使得Switch能够控制任何实现了这个接口的东西，这也就满足了DIP和OCP原则。如下面图2所示：



解决方案三：
　　上面图2所示解决方案，违返了单一职责原则(SRP)，它把Switch和Light绑定在一起，而它们可能会因为不同的原因而改变。这种问题可以采用ADAPTER模式来解决，适配器从Switchable 派生并委托给Light，问题就被优美的解决了，现在，Switch就可以控制任何能够被打开或者关闭的对象。但是这也需要会出时间和空间上的代价来换取。如下面图3所示：



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

参考文献

1. 设计模式-可复用面向对象软件的基础 -- 李英军等译
2. 重构-改善既有代码的设计 -- 侯捷等译
3. 敏捷软件开发-原则、模式与实现 -- 邓辉译