敏捷软件开发宣言
敏捷软件开发宣言
我们正在通过亲身实践以及帮助他人实践，揭示
更好的软件开发方法。通过这项工作，我们认为：
个体和交互
胜过
过程和工具
可以工作的软件
胜过
面面俱到的文档
客户合作
胜过
合同谈判
响应变化
胜过
遵循计划
虽然右项也具有价值，
但我们认为左项具有更大的价值。
Kent Beck
James Grenning
Robert C.Martin
Mike Beesle
Jim Highsmith
Steve Mellor
Arie van Bennekum
Andrew Hunt
Ken Schwaber
Alistair Cockburn
Ron Jeffries
Jeff Sutherland
Ward Cunningham
Jon Kern
Dave Thomas
Martin Fowler
Brian Marick
敏捷宣言遵循的原则
我们遵循以下原则：
l
我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
l
即使到了开发的后期，也欢迎改变需要。敏捷过程利用变化来为客户创造竞争优势。
l
经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。
l
在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
l
围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。
l
在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
l
工作的软件是首要的进度度量标准。
l
敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
l
不断地关注优秀的技能和好的设计会增强敏捷能力。
l
简单――使未完成的工作最大化的艺术――是根本的。
l
最好的构架、需求和设计出自组织的团队。
l
每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整
面向对象设计的原则
SRP
单一职责原则
就一个类而言，应该仅有一个引起它变化的原因。
OCP
开放一封闭原则
软件实体（类、模块、函数等）应该是可以扩展的，但是不可修改。
LSP
Liskov替换原则
子类型必须能够替换掉它们的基类型。
DIP
依赖倒置原则
抽象不应该依赖于细节。细节应该依赖于抽象。
ISP
接口隔离原则
不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的类层次结构。
REP
重用发布等价原则
重用的粒度就是发布的粒度。
CCP
共同封闭原则
包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包产生影响，则将对该包中的所有类产生影响，而对于其他的包不造成任何影响。
CRP
共同重用原则
一个包中的所有类应该是共同重用的。如果重用了包中的一个类，那么就要重用包中的所有类。
ADP
无环依赖原则
在包的依赖关系图中不允许存在环。
SDP
稳定依赖原则
朝着稳定的方向进行依赖。
SAP
稳定抽象原则
包的抽象程度应该和其稳定程度一致。
极限编程实践
完整团队
XP项目的所有参与者（开发人员、业务分析师、测试人员等等）一起工作在一个开放的场所中，他们是同一个团队的成员。这个场所的墙壁上随意悬挂着大幅的、显著的图表以及其他一些显示他们进度的东西。
计划游戏
计划是持续的、循序渐进的。每2周开发人员就为下2周估算候选特性的成本，而客户则根据成本和商务价值来选择要实现的特性。
客户测试
作为选择每个所期望的特性的一部分，客户定义出自动验收测试来表明该特性可以工作。
简单设计
团队保持设计恰好和当前的系统功能相匹配。它通过了所有的测试，不包含任何重复，表达出了编写者想表达的所有东西，并且包含尽可能少的代码。
结对编程
所有的产品软件都是由两个程序员、并排坐在一起在同一台机器上构建的。
测试驱动开发
程序员以非常短的循环周期工作，他们先增加一个失败的测试，然后使之通过。
改进设计
随时改进糟糕的代码。保持代码尽可能的干净、具有表达力。
持续集成
团队总是使系统完整地被集成。
集体代码所有权
任何结对的程序员都可以在任何时候改进任何代码。
编码标准
系统中所有的代码看起来就好像是被单独一个――非常值得胜任的――人编写的。
隐喻
团队提出一个程序工作原理的公共景像。
可持续的速度
团队只有持久才有获胜的希望。他们以能够长期维持的速度努力工作。他们保存精力，他们把项目看作是马拉松长跑，而不是全速短跑。
页:
[1]