zoukankan      html  css  js  c++  java
  • 敏捷软件开发要点

           下面的文字来自于《敏捷软件开发 原则、模式和实践》一书,作者是Robert C. Martin。我把这些文字发布在这里,希望对敏捷软件开发还不是很了解的朋友所有帮助。我推崇这本书,是因为它提出了许多有价值的软件项目管理的理念,以及软件设计思想和方法,其中,很多可以直接用在我们的工作中,或用来指导我们的工作----敏捷软件开发是务实的。

    一、敏捷软件开发宣言
    我们正在通过亲身的实践以及帮助他人实践,揭示更好的软件开发方法。通过这项工作,我们认为:
    个体和交互                胜过        过程和工具
    可以工作的软件        胜过        面面俱到的文档
    客户合作                    胜过        合同谈判
    响应变化                    胜过        遵循计划

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

    二、敏捷宣言遵循的原则
    我们遵循以下原则:

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

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

    四、极限编程实践
    1、完整团队
            XP项目的所有参与者(开发人员、业务分析师、测试人员等)一起工作在一个开放的环境中,他们是同一个团队的成员。这个场所的墙壁上随意悬挂着大幅的、显著的图表以及其它一些显示他们进度的东西。
    2、计划游戏
            计划是持续的、循序渐进的。每2周开发人员就要为下2周估算候选特性的成本,而客户则根据成本和商务价值本选择要实现的特性。
    3、客户测试
            作为选择每个所特性的一部份,客户定义出自动验收测试来表明该特性可以工作。
    4、简单设计
            团队保持设计恰好和当前的系统功能匹配。它通过了所有的测试,不包含任何重复,表达出了编写者想表达的所有东西,并且包含尽可能少的代码。
    5、结对编程
            所有的产品软件都是由两个程序员、并排坐在一起在同一台机器上构建的
    6、测试驱动开发
            程序员以非常短循环周期工作,他们先增加一个失败的测试,然后使它通过。
    7、改进设计
            随时改进糟糕的代码。保持代码尽可能的干净,具有表达力。
    8、持续集成
            团队总是使系统完整地被集成。
    9、集体代码所有权
            任何结对的程序员都可以在任何时候改进任何代码
    10、编码标准 
            系统中的所有代码看起来好像是被单独一个--非常值得信任的--人编写的
    11、隐喻
            团队提出一个程序工作原理的公共景象
    12、可持续速度
            团队只有持久才有获胜的希望。他们以能够长期维持的速度努力工作。他们保存精力,他们把项目看作是马拉松长跑,而不是全速短跑。




查看全文
  • 相关阅读:
    遍历Map集合:java.util.Map.Entry、KeySet两种方式
    Tomcat学习笔记(二)—— 一个简单的Servlet容器
    Tomcat学习笔记(一)一个简单的Web服务器
    对检查性异常和非检查性异常的理解
    org.apache.commons.beanutils.BeanMap简单使用例子
    (转)Java对象克隆(Clone)及Cloneable接口、Serializable接口的深入探讨
    试简述湿式报警阀调试时应满足的要求
    消防水系泵验收时应满足哪些要求
    消防水泵接合器的检查方法和技术要求如下: (1)查看水泵接合器的外观是否有瑕疵,油漆是否完整,形状尺寸和安装尺寸与提供的安装图纸是否相符; (2)对照设计文件查看选择的水泵接合器的型号、名称是否准确、一致; (3)水泵接合器的设置条件是否具备,其设置位置是否是在室外便于消防车接近和使用的地点; (4)检查水泵接合器的外形与室外消火栓是否雷同,以免混淆而延误灭火; (5)检查消防供水设施 官网及阀门
    消防给水和消火栓系统(一)
  • 原文地址:https://www.cnblogs.com/watsonyin/p/335761.html
  • Copyright © 2011-2022 走看看