【IT168 分析评论】

    我们正在通过亲身实践以及帮助他人实践，揭示更好的软件开发方法。通过这项工作，我们认为：

    人和交互重于过程和工具

    可以工作的软件重于面面俱到的文档

    客户合作重于合同谈判

    随时应对变化重于遵循计划

    虽然右项也有其价值，但我们认为左项更加重要。

    敏捷宣言遵循的原则

    我们遵循以下原则：

    我们最优先要做的是通过尽早地、持续地交付有价值的软件来满足客户需要。

    我们欢迎需求的变化，即使到了开发后期。敏捷过程能够驾驭变化，为客户创造竞争优势。

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

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

    围绕斗志高昂的人构建项目。给他们提供所需的环境和支持，并且信任他们能够完成任务。

    在团队内部，最有效率也最有效果的信息传达方式，就是面对面的交谈。

    可以工作的软件是进度主要的度量标准。

    敏捷过程提倡可持续开发。出资人、开发者和用户应该总是保持稳定的开发速度。

    对卓越技术和良好设计的不断追求有助于提高敏捷性。

    简单——尽量减少工作量的艺术是至关重要的。

    最好的构架、需求和设计都源自自我组织的团队。

    每隔一定时间，团队都要总结如何更有效率，然后相应地调整自己的行为。

    面向对象设计的原则

    SRP：单一职责原则

    一个类应该只有一个发生变化的原因。

    OCP：开放—封闭原则

    软件实体（类、模块、函数等）应该是可以扩展的，但是不可修改。

    LSP：Liskov替换原则

    子类型必须能够替换他们的基类型。

    DIP：依赖倒置原则

    抽象不应该依赖于细节。细节应该依赖于抽象。

    ISP：接口隔离原则

    不应该强迫客户依赖并未使用的方法。接口属于客户，而不属于它所在的类层次结构。

    REP：重用—发布等价原则

    重用的粒度就是发布的粒度。

    CCP：共同封闭原则

    包中的所有类对于同一种性质的变化应该是共同封闭的。一个变化若对一个封闭的包产生影响，则将对该包中的所有类产生影响，而对于其他包则不造成任何影响。

    CRP：共同重用原则

    一个包中的所有类应该是共同重用的。如果重用了包中的一个类，那么也就相当于重用了包中的所有类。

    ADP：无环依赖原则

    在包的依赖关系图中不允许存在环。

    SDP：稳定依赖原则

    朝着稳定的方向进行依赖。

    SAP：稳定抽象原则

    包的抽象程度于其稳定程度一致。

    极限编程实践

    完整团队

    XP项目的所有参与者（开发人员、业务分析师、测试人员等）一起工作在一个开放的场所，他们是同一个团队的成员。这个场所的墙壁上随意悬挂着大幅的、显眼的图表以及其他一些显示进度的东西。

    计划游戏

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

    客户测试

    选择每个所需的特性时，由客户定义表明该特性可以工作的自动验收测试。

    简单设计

    团队要使设计始终恰好适合当前系统的功能。这样的设计能通过所有的测试，既不包含任何重复，又表达出了编写者想表达的所有东西，并且包含尽可能少的代码。

    结对编程

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

    测试驱动开发

    程序员以非常短的循环周期工作，他们先编写一个失败的测试，然后使之通过。

    改进设计

    及时改进糟糕的代码，不留到第2天。保持代码尽可能地干净、具有表达力。

    持续集成

    团队总是使系统完整地被集成。

    代码集体所有

    任何结对的程序员都可以在任何时候改进任何代码。

    编程规范

    系统中所有的代码看起来就好像是由单个合格的程序员编写的。

    隐喻

    团队应该对程序如何工作形成共识。

    可持续的速度

    团队应该长期可持续发展。他们以能够长期维持的速度努力工作。他们保存精力，把项目看作是马拉松长跑，而不是全速短跑。