敏捷开发原则

敏捷开发原则


1.尽早的，经常性的进行交付。努力在项目刚开始的几周内交付一个具有基本功能的系统，然后努力坚持每两周就交付一个功能渐增的系统。
2.团队努力保持软件结构的灵活性。这样能够欢迎需求的变化（变化可以为客户创造竞争优势）。因此要学习面向对象设计的原则和模式，这会帮助我们维持这种灵活行。
3.要经常性交付软件，并且是可以工作的软件。周期越短越好。不赞成交付大量文档。
4.业务人员和开发人员要进行频繁的交互，天天一起工作。
5.围绕被激励起来的个人来构建项目，改变对团队工作的阻碍的过程步骤。
6.在团队内部，最有效果并且富有效率的传递信息的方法，就是面对面的交谈，而非文档。
7.工作的软件是首要的进度度量标准，而不是那些基础结构或者文档。
8.保持一个长期和恒定的开发速度。尽量不要拖延和加班，要善于调整速度完成高质量的标准。
9.关注好的设计和技能，编写高质量的代码。如果今天制造了混乱，不要拖到明天去清理。
10.简单。不要预测明天的问题。高质量完成今天的工作，深信如果明天发生了问题，也会狠容易的处理。
11.每一个成员都具有项目中所有方面的参与劝。最好的构架、需求和实际来自于自组织的团队。
12.每个一段时间，团队会在如何才能更有效的工作方面进行反省，然后对自己的行为进行调整。





原则

1. 我们最优先要做的是通过尽早地、持续地交付有价值的软件来使客户满意。
2. 我们欢迎需求的变化，即使到了开发后期。敏捷过程能够驾驭变化，为客户创造竞争优势。
3. 经常交付可以工作的软件 ，从几个星期到 几个月，时间间隔越短越好。
4. 在整个项目开发期间，业务人员和开发人员必须朝夕工作在一起。
5. 围绕斗志昂扬的人构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。
6. 在团队内部，最有效率也最有效果的信息传达方式，就是面对面的交谈。
7. 可以工作的软件是 进度主要的度量标准。
8. 敏捷过程提倡可持续开发。出资人、开发者和用户应该总是保持稳定的开发速度。
9. 对卓越技术和良好设计的不断追求有助于提高敏捷性。
10. 简单——尽量减少工作量的艺术是至关重要的。
11. 最好的架构、需求和设计都源于自我组织的团队。
12. 每隔一定时间，团队都要总结如何更右效率，然后相应地调整自己的行为。

极限编程实践

完整团队 用户故事 短交付周期 验收测试 结对编码 测试驱动开发

集体所有权 持续集成 可持续的开发速度 开放的工作空间 计划游戏

简单设计 重构 隐喻

避免设计的臭味

· 僵化性 （ rigidity ） ——设计难以改变。
· 脆弱性（ fragility ）——设计易于遭到破坏。
· 顽固性（ immobility ）——设计难以重用。
· 粘滞性（ viscosity ）——难以做正确的事情。
· 不必要的复杂性（ needless complexity ）——过分设计。
· 不必要的重复（ needless repetition ）——滥用鼠标进行复制、黏贴。
· 晦涩性（ opacity ）——混乱的表达。

设计原则

· 单一职责原则（ SRP ）：一个类应该只有一个发生变化的原因。
· 开放封闭原则（ OCP ）：软件实体应该对扩展开放，对修改关闭。
· Liskov 替换原则（ LSP ）：子类型（ subtype ）必须能够替换掉它的基类型（ base type ）。
· 依赖倒置原则（ DIP ）： a. 高层模块不应该依赖于低层模块。二者都应该依赖于抽象。 b. 抽象不应该依赖于细节。细节应该依赖于抽象。
· 接口隔离原则（ ISP ）：不应该强迫客户程序依赖并未使用的方法。
· DRY ： Don’t repeat yourself Principle 。通过抽取公共部分放置在一个地方避免代码重复。
· 封装变化 （ Encapsulate what varies ）。
· 面向接口编程而不是实现（ Code to an interface rather than to an implementation ）。
· 优先使用组合而非继承（ Favour Composition Over Inheritance ）。

包和组件的设计原则
重用-发布等价原则（Reuse-Release Equivalence Principle, REP）：重用的粒度就是发布的粒度。
共同重用原则（Common-Reuse Principle, CRP）：一个组件中的所有类应该是共同重用的。如果重用了组件中的一个类，那么就要重用组件中的所有类。
共同封闭原则（Common-Closure Principle, CCP）：组件中的所有类对于同一种性质的变化应该是共同封闭的。一个变化若对一个封闭的组件产生影响，则对该组件中的 所有类产生影响，二对于其他组件则不造成任何影响。
无环依赖原则（Acycle-Dependencies Principle, ADP）：在组件的依赖关系图中不允许存在环。
稳定依赖原则（Stable-Dependencies Principle, SDP）：朝着稳定的方向进行依赖。
稳定抽象原则（Stable-Abstraction Principle, SAP）：组件的抽象程度应该与其稳定程度一致。


1.SRP单一职责原则[适用于类功能]
(就一个类而言,应该仅有一个引起它变化的原因.)
详细说明:
如果一个类承担的职责过多,就等于把这些职责耦合在一起.
一个职责的变化可能会削弱或者抑制这个类完成其它职责的能力.
这种耦合会导致脆弱的设计,当变化发生时,设计会遭受到意想不到的破坏.
结论:
它是所有类设计原则最简单的,也是最难正确使用的.
我们会自然的把职责结合在一起,软件设计真正要做的内容就是发现职责并把那些职责相互分离.

2.OCP开放-封闭原则[适用于类抽象]
(软件实体(类,模块,函数...)应该是可以扩展的,但是不可以修改.)
详细说明:
OCP=对于扩展是开放的,对于修改是封闭的.
如果程序中的一处改动就会产生连锁反应,导致一系列相关模块的改动,那么设计就有臭味.
OCP建议我们如果要对系统进行重构,就只需要添加新的代码,而不必改动已经正常运行的代码.
结论:
在许多方面,OCP都是面向对象设计的核心.
尊循它可以带来巨大的好处(程序的灵活性,可重用性,可维护性).
在代码中肆意使用OCP也不是一个好主意.
正确的做法是：开发人员仅仅对程序中呈现频繁变化的部分做出抽象！拒绝不成熟的抽象和抽象本身一样重要!

3.LSP Liskov替换原则[适用于类层次]
(子类型必须能够替换掉它们的基类型.)
详细说明:
Barbara Liskov在1988年说道:
Liskov替换性质:若对每个类型S的对象O1,都存在一个类型T的对象O2,
在所有针对类型T编写的程序P中,用O1代换O2后,程序P行为功能不变,则类型S是类型T的子对象.
结论:
LSP是使用OCP开放-封闭原则成为可能的主要原则之一,
正是子类型的可替换性才能用基类类型(基类引用或者指针)的模块在无需修改的情况下就可以扩展.
这种可替换性是开发人员可以隐式依赖的东西.
因此,如果没有显示的强制基类类型的契约,那么代码就必须良好并明显的表达出这一点.
术语"IS-A"不能作为子类型的定义,
子类型的正确定义是"可替换性","可替换性"可以通过显式或者隐式的(动态绑定必须用基类类型)契约.

4.DIP依赖倒置原则[适用于类层次]
(抽象不应该依赖细节.细节应该依赖抽象.)
详细说明:
a.高层模块不应该依赖于低层模块,二者都应该依赖抽象(使用接口或者虚类来连接).
b.抽象不应该依赖于细节,细节应该依赖于抽象.
结论:
使用传统的过程化程序设计方法所创建出来的依赖关系结构和策略是依赖于细节.
DIP使得细节和策略都依赖于抽象,并且常常为客户定制服务接口.
事实上,这种依赖关系的倒置是好的面向对象的程序设计的标记.
DIP正确应用对于可重用框架是必须的,对于构建在变化面前富有弹性的代码也是非常重要的.
由于抽象和细节被DIP彼此隔离,所以代码也非常容易维护.


5.ISP接口隔离原则[适用于类的接口]
不应该强迫客户程序依赖于它们不用的方法.
接口属于客户,不属于它所在的类层次结构.
详细说明:
分离客户就是分离接口.分离接口有2种方法:委托和多重继承
接口隔离原则是用来处理胖接口所具有的缺点.
如果类接口不是内聚的,就表示该类的接口是胖的,需要减肥.
减肥的原则是接口分成多组方法,每一组方法都服务于一组不同的客户程序!
客户程序面对的就是多个具有内聚接口的抽象基类.

结论:
胖类会导致它们的客户程序之间产生不正常的有害的耦合关系.
当客户程序要求胖类进行一个改动时,会影响到所有其它户程序.
因此,程序应该仅仅依赖于它们实际调用的方法.
通过把胖类的接口分解为多个特定的客户程序的接口,可以实现这个目标.
每个特定于客户程序的接口仅仅声明它自己调用的函数.
解除了类的客户程序之间依赖关系,使它们互不依赖.


6.REP重用发布等价原则[适用于包]
(重用的粒度就是发布的粒度)
详细说明:
当你重用别人一个类库时,你的期望是什么？
当然是好的文档,可以工作的代码,规格清晰的接口!
你希望作者会一直维护类库代码,当作者都把类库的接口和功能进行任何改变时,你希望得到通知.
代码的作者把它们的软件组织到一个包中(dll,jar,...),所以我们重用的粒度就是包的发布粒度.
结论:
一个包的重用粒度和和发布粒度一样大,由于重用性是基于包的,所以可重用的包必须包含可重用的类.


7.CCP共同封闭原则[适用于包]
(包中的所有类对于同一类性质的变化应该是共同封闭的.
一个变化若对一个包产生影响,则将对该包中的所有类产生影响,而对于其它包不造成任何影响.)
详细说明:
这是SRP单一职责原则对包的重新规定.这规定了一个包不应该包含多个引用包变化的原因.
在大多数应用中,可维护性超过可重用性.
代码更改:如果代码要更改,原意更改都集中在一个包中,而不是分布于多个包中.
代码发布:我们也只发布更改中的包!
结论:
CCP鼓励我们把可以由于同样的原因而更改的所有类共同聚集在同一个包中.

8.CRP共同重用原则[适用于包]
(一个包中的所有类应该是共同重用的.
如果重用了包中的一个类,那么就要重用包中的所有类.)
详细说明:
一个包中的所有类应该是共同重用的.
结论:
如果重用了包中的一个类,那么就要重用包中的所有类.
这个原则可以帮助我们决定哪些类应该放进同一个包中.

9.ADP无环依赖原则[适用于包]
(在包的依赖关系图中不允许存在环.)
详细说明:
如果开发环境中有许多开发人员都在更改相同的源代码文件集合的情况,
因为有人比你走的晚,且改了你所依赖一些东西(类或者方法),第二天来上班,
你昨天完成的功能,今天不能正常工作,那么就会发生"晨后综合症"!
针对此问题有两个解决方案:"每周构建"和"消除依赖环"
每周构建:应用于中等规模的项目中,它的工作方式为:每周1-4,开发人员各自工作在私人的代码空间,周5-6联合调试！
消除依赖环:通过把开发环境划分成可发布的包,可以解决依赖环.
结论:
解决包之间的依赖环有两个主要方法：
1.使用依赖倒置原则,在类和依赖类之前添加一个依赖的接口或者抽象类,解除依赖环.
2.添加新类,把类和依赖类之间的依赖移到一个新的类,解除依赖环.


10.SDP稳定依赖原则[适用于包]
(朝着稳定的方向进行依赖.)
详细说明:
设计不是完全固定的,要使设计可维护,某种程序的易变性是必要的.
使用这个原则,我们可以创建对某些变化类型敏感的包.

其它的包不要依赖这个要变的包.
软件包就可以分为稳定包和可变包!
如何识别稳定包和可变包？如果许多其它的包都依赖此包,那么它就是稳定包,否则就是可变包！
把包放在不同的位置,它的稳定性是不同的.
如何计算一个包的不稳定性？(输入耦合度Ca,输出耦合度Ce)
不稳定值=Ce/(Ca+ce),此值越低越稳定!
结论:
把可变包不稳定值降低的方法是:为它加上一个抽象外衣(interface/抽象类),其它包调用抽象外衣!
可变包为抽象外衣的实现!


11.SAP稳定抽象原则[适用于包]
(包的抽象程序应该和其它稳定程序一致.)
详细说明:
此原则把包的稳定性和抽象性联系到一起.
一个稳定的包应该是抽象的,这样它的稳定性就不会使其无法扩展;
一个不稳定的包应该具体的, 这样它的不稳定性使代码易于修改.

结论:
它指出一个包有时候应该达到部分是可抽象的,部分是不稳定的原则