敏捷开发(一)

一、 敏捷软件开发宣言
1、个体和交互胜过过程和工具
人是获得成功的最为重要的因素。如果团队中没有优秀的成员，那么就是使用好的过程也不能从失败中挽救项目，但是，不好的过程却可以使最优秀的团队成员失去效用。如果不能作为一个团队进行工作，那么即使拥有一批优秀的成员也一样会惨败。
宣言要求建立优秀的团队，注重沟通；对于工具，先尝试简单的小工具，直到其不能满足需求在考虑更换。

2、可以工作的软件胜过面面俱到的文档
没有文档的软件是一种灾难。代码不是传达系统原理和结构的理想媒介。团队更需要编制易于阅读的文档，来对系统及其设计决策的依据进行描述。然而，过多的文档 比过少的文档更糟。编制众多的文档需要花费大量的时间，并且要使这些文档和代码保持同步，就要花费更多的时间。如果文档和代码之间失去同步，那么文档就会变成庞大的、复杂的谎言，会造成重大的误导。
宣言指出指出文档应该论述系统的高层结构和概括的设计原理。直到迫切需要并且意义重大时才来编制文档。在给新的团队成员传授知识方面，提出最好的两份文档是代码和团队。

3、客户合作胜过合同谈判
不能像订购日用品一样来订购软件。你不能够仅仅写下一份关于你想要的软件的描述，然后就让人在固定的时间内以固定的
价格去开发它。所有用这种方式来对待软件 项目的尝试都以失败而告终。有时，失败是惨重的。告诉开发团队想要的东西，然后期望开发团队消失一段时间后就能够交付一个满足需要的系统来，这对于公司的 管理者来说是具有诱惑力的。然而，这种操作模式将导致低劣的质量和失败。成功的项目需要有序、频繁的客户反馈。不是依赖于合同或者关于工作的陈述，而是让软件的客户和开发团队密切地在一起工作，并尽量经常地提供反馈。
宣言要求要求与客户一起工作，随时捕获客户的需求变化并作出应对。
 

4、响应变化胜过遵循计划
响应变化的能力常常决定着一个软件项目的成败。当我们构建计划时，应该确保计划是灵活的并且易于适应商务和技术方面
的变化。较好的做计划的策略是：为下两周做详细的计划，为下三个月做粗略的计划，再以后就做极为粗糙的计划。我们应该清楚地知道下两周要完成的任务，粗略地了解一下以后三个月要实 现的需求。至于系统一年后将要做什么，有一个模糊的想法就行了。
宣言提倡详细计划只做两周，三个月的粗略计划，再长时间的计划就更粗略。这样计划就能不花很大成本随需求的变化而变化。 

 

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

 

三、面向对象设计的原则
1、单一职责原则（SRP）
就一个类而言，应该仅有一个引起它变化的原因。

2、开放封闭原则（OCP）
软件实体（类、模块、函数）等应该是可以扩展的，但是不可以修改。

3、Liskov替换原则（LSP）
子类型必须能够替换掉它们的基类型。

4、依赖倒置原则（DIP）
抽象不应该依赖于细节。细节应该依赖于抽象。

5、接口隔离原则（ISP）
不应该强迫客户依赖于它们不用的方法，接口属于客户，不属于它所在的类层次结构。使用多个隔离的接口，
比使用单个接口好。也就是说，一个类对另外一个类的依赖性应当是建立在最小的接口上的。

包设计-内聚原则
6、重用发布等价原则（REP）
重用的粒度等于发布的粒度。只有通过一个跟踪系统发布的组件才可以被有效重用，此粒度通常以包为单位。这就是说，
为了有效地重用，代码必须是以包为单位，完整且透明。只有真正发布的，且透明的完整代码才存在被重用的可能性。
同时，重用也驱动我们在写代码时构建更小的包，业务逻辑分离得更彻底并保持完整。

7、共同封闭原则（CCP）
包中的所有类对于同一类性质的变化应该是共同封闭的。 一个变化若对一个包产生影响，则将对该包中的所有类产生影响，而对于其他的包不造成任何影响。简单地说，一起修改的类，应该组合在一起（同一个包里）。如果必须修改应用程序里的代码，我们希望所有的修改都发生在一个包里（修改关闭），而不是遍布在很多包里。

8、共同重用原则(CRP)
一个包中的所有类应该是共同重用的。如果重用了包中的一个类，就应该重用包中的所有类。相互之间没有紧密联系的类
不应该在同一个包中。
REP 和 CRP 关注的都是重用性， CCP 关注的是可维护性。

包设计-耦合原则
9、无环依赖原则（ADP）
在包的依赖关系图中不允许存在环。如果存在2个或2个以上的包，它们之间的依赖关系图出现了环状，我们就称包之间存
在循环依赖关系。例：A依赖B，B依赖C，C依赖A，形成了一个环状依赖。

如果包的依赖关系图中存在环，就会导致环上的所有软件包必须同时发布，它们形成了一个高耦合体，当项目的规模大
到一定程度，包的数目变多时，包与包之间的关系便变得错综复杂，各种测试也将变得非常困难，常常会因为某个
不相关的包中的错误而使得测试无法继续，无疑增加了发布后的验证难度。
循环依赖的打破方法：
（1）创建新的包

  这样，包的依赖关系就从A->B->C->A变成了：
   A->B->C->D; A->D
（2）DIP与ISP设计原则
ISP（接口分隔原则）可以剔除没用到的接口。DIP（依赖倒置原则）在类的调用之间引入抽象层。
如下图,包A依赖包B（因为包A中的类U使用了包B中的类X）；反过来，包B又依赖包A（因为包B中的类Y使用了包A中的类V），包A，包B之间就形成了一种循环依赖。

我们使用DIP设计原则为V抽象一个接口IVforY，并把该接口放在B包中。这样就把Y对V的调用转化为：V继承IVforY，
Y调用IVforY，这样一来，包B中的类就不依赖任何包A中的类了。如下图：

10、稳定依赖原则（SDP）
朝着稳定的方向进行依赖。如果一个包被很多包所依赖，那么它就是稳定的，因为要使所有依赖于它的包能够相容于
对它所做的更改，往往需要非常大的工作量。一个系统中的所有包并非都应该都是稳定的，因为如果那样的话，
系统将很难更改。 SDP 指导我们处理稳定包和不稳定包之间的关系：不稳定的包应该依赖于稳定的包，一个包应该
依赖于比他更稳定的包。你设计了一个不稳定的包，期望它能随变化容易地更改，可当它被一个稳定的包依赖后，
它就再也不会易于更改了，这就使软件难于修改和变化。

11、稳定抽象原则（SAP）
包的抽象程度应该和其稳定程度一致。最稳定的包应该是最抽象的包。不稳定的包应该是具体的包。包的抽象程度
跟它的稳定性成正比。一个系统的高层构架和设计决策应该被放进稳定的包中，因为这些构架决策不应该经常改变，
然而稳定包的不易更改的特点会使这些架构决策不灵活，显然只用稳定性来度量一个包是不够的， SAP 告诉我们：
稳定的包也应该是抽象的。它应该包含抽象类，系统通过在其他包中实现该稳定包中的抽象类来进行扩展，
而该稳定包无需修改，从而在保持稳定的同时也不失灵活性。

 

四、极限编程实践 
1、完整团队
  XP项目的所有参与者（开发人员、业务分析师、测试人员等等）一起工作在一个开放的场所中，他们是同一个团队

   的成员。这个场所的墙壁上随意悬挂着大幅的、显著的图表以及其他一些显示他们进度的东西。

2、计划游戏
  计划是持续的、循序渐进的。每2周，开发人员就为下2周估算候选特性的成本，而客户则根据成本和商务价值来选择
  要实现的特性。

3、客户测试
    作为选择每个所期望的特性的一部分，客户定义出自动验收测试来表明该特性可以工作。

 

4、简单设计 
  团队保持设计恰好和当前的系统功能项匹配。它通过了所有的测试，不包含任何重复，表达出了编写者想表达的所有
  东西，并且包含尽可能少的代码。

5、结对编程
  所有的产品软件都是由两个程序员、并排坐在一起在同一台机器上构建的。   

    
6、测试驱动开发
  程序员以非常短的循环周期工作，他们先增加一个失败的测试，然后使之通过。

7、改进设计
  随时改进糟糕的代码。保持代码尽可能的干净、具有表达力。

8、持续集成
  团队总是是系统完整的被集成。

9、集体代码所有权
  任何结对的程序员都可以在任何时候改进任何代码。

10、编码标准
  系统中所有的代码看起来就好像是被单独一个——非常胜任的——人编写的。

11、隐喻
  团队提出一个程序工作原理的公共景象。

12、可持续的速度
  团队只有持久才有获胜的希望。他们以能够长期维持的速度努力工作。他们保存精力，他们把项目看作是马拉松长跑，
  而不是全速短跑。