精华内容
下载资源
问答
  • 3、根据传统开发如果出问题,问题并不在于执行,问题在于计划驱动方法所信奉理念根本无法适应大多数产品开发工作所固有不确定性。 可变性和不确定性 采用积极有帮助可变性 采用迭代和增量开发 通过...

    1、传统开发一般是,分析、设计、编码、测试、运行,称之为“计划驱动”开发。

    2、产品开发很少是按照计划进行的。

    3、根据传统开发如果出问题,问题并不在于执行,问题在于计划驱动方法所信奉的理念根本无法适应大多数产品开发工作所固有的不确定性。

     

    可变性和不确定性

    • 采用积极有帮助的可变性
    • 采用迭代和增量开发
    • 通过见识、调整和透明来利用可变性
    • 同时减少各种的各样的不确定因素
    • 不确定性(方法不确定性、结果不确定性)

    敏捷开发的原则

    • 不到最后时刻,不轻易做决定
    • 承认无法一开始就把事情做对
    • 偏好适应性,探索式的方法
    • 用经济合理的方法积极主动的接受变化
    • 在预测性的事情工作和适应性的适时工作之间做出平衡

     

    转载于:https://www.cnblogs.com/JeneryYang/p/8888877.html

    展开全文
  • 涵盖敏捷开发的基本技能和原则。 大量基于示例,并且没有太多抽象描述。
  • 以下内容参考敏捷软件开发原则、模式与实践以及设计模式之面向对象与类基础特征概念、设计模式之面向对象七大基本原则 面向对象基础概念 面向对象三大基本特征 封装 封装是把过程和数据包围起来,对数据访问只能...

    以下内容参考敏捷软件开发原则、模式与实践以及设计模式之面向对象与类基础特征概念设计模式之面向对象七大基本原则

    面向对象基础概念

    面向对象三大基本特征

    封装

    封装是把过程和数据包围起来,对数据的访问只能通过已定义的界面。

    继承

    继承是一种类的层次模型,并且允许和鼓励类的重用,它提供了一种明确表述共性的方法。

    多态

    多态性是指允许不同类的对象对同一消息作出响应。多态性包括编译时多态和运行时多态。
    主要作用就是用来将接口和实现分离开,改善代码的组织结构,增强代码的可读性。
    在某些很简单的情况下,或许我们不使用多态也能开发出满足我们需要的程序,但大多数情况,如果没有多态,就会觉得代码极其难以维护。

    面向对象通过类和对象来实现抽象,实现时诞生了三个重要的特性,也就是由于这三个特性才衍生出了各种各样的设计模式。

    面向对象类关系

    通过大量代码和经验可以得知,类与类之间主要有6种关系模式,这六种模板写法导致了平时书写代码的不同耦合度。具体如下所列(耦合度依次增强排列):

    1. 依赖关系
    2. 关联关系
    3. 聚合关系
    4. 组合关系
    5. 继承关系
    6. 实现关系

    为了记住类与类之间的关系,我自己总结了一句话方便记忆:《衣(依赖)冠(关联)剧(聚合)组(组合)纪(继承)实(实现)》。详细解释可以参考设计模式之面向对象与类基础特征概念,写的很有意思。

    什么是敏捷设计

    实际上满足工程设计标准的唯一软件文档,就是源代码清单。 —Jack Reeves

    软件腐化

    事实证明,随着软件开发的不断迭代,代码会变得越来越难以维护,更改代码越来越困难,当你的代码出现以下的特征时,就表明软件正在腐化。

    • 僵化性(Rigidity):很难对系统进行改动,因为每个改动都会迫使许多对系统其它部分的其他改动。
    • 脆弱性(Fraglity):对系统的改动会导致系统中和改动的地方在概念上无关的许多地方出现了问题。
    • 牢固性(Immobility):很难解开系统的纠结,使之成为一些可在其它系统中重用的组件
    • 粘滞性(Viscosity):做正确的事情比做错误的事情要困难(做错误的事情是容易的,但是做正确的事情却很难)
    • 不必要的复杂性(Needless Compxity):设计中包含有不具任何直接好处的基础结构
    • 不必要的重复(Needless Repetition):设计中包含重复的结构,而该重复的结构本可以使用单一的抽象进行统一
    • 晦涩性(Opacity):很难理解、阅读、没有很好的表现出意图

    敏捷开发

    敏捷设计是一个过程,不是一个事件。它是一个持续的应用原则、模式以及实践来改进软件的结构性和持续性的过程。它致力于保持系统设计在任何时间都尽可能的简单、干净以及富有表现力。

    面向对象设计原则

    以下所有的原则都是为了构建高内聚、低耦合的系统

    单一职责原则(SRP)

    就一个类来说,应该有一个引起它变化的原因

    为什么需要SRP?

    如果一个类承担的职责过多,就等于将这些类耦合到了一起。一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这样的耦合会导致脆弱(fragile)的设计,当变化发生的时候,设计会遭受到意想不到的破坏。

    职责的意思是“变化的原因”

    如何判断是否违反了SRP

    如果你能够想到多余一个的动机去改变一个类,那么这个类就具有多于一个的职责。但是有时候这是比较困难的。如以下的这个例子,大多数人会认为这个接口是非常合理的。

    interface Modem
    {
        public void dial(String pro);
        public void hangup();
        public void send(char c);
        public void recv();
    }

    从正常逻辑来看,一个Modem就是具有这些功能,连接、断开、发送、接收。然而,该接口中却显示出两个职责。第一个职责是连接管理,第二个职责是数据通信

    那么这两个职责该被分离吗?

    这依赖于应用程序变化的方式。

    • 如果两个职责不是同时进行变化,就需要分离,不分离就具有僵化性的臭味。
    • 如果两个职责是同时变化,就不分离,分离了就具有不必要的复杂性的臭味。

    结论

    SRP是所有原则中最简单的之一,也是最难正确运用的之一。我们会自然而然地将职责结合在一起。软件设计真正要做的许多内容,就是发现职责并将那些职责相互分离。事实上,我们将要论述的其他原则都会以这样或者那样的方式回到这个问题上。

    开放-封闭原则(OCP)

    软件实体(类、模块、函数等等)应该是可以扩展的,但是不可修改的

    为什么需要OCP?

    OCP相当于一种策略来帮助我们构建健壮的系统,使系统在面对需求的改变可以保持相对稳定,从而使系统在第一个版本以后可以不断推出新的版本。

    OCP描述

    遵循开放-封闭原则设计出的模块具有两个主要的特征。

    • 对于扩展是开放的(Open for extension)

      这意味着模块的行为是可以扩展的。当应用的需求改变时,我们可以对模块进行扩展,使其具备满足那些变化的新行为。换句话说,我们可以改变模块的功能。

    • 对于更改是封闭的(Closed for modification)

      对模块行为进行扩展时,不必改动模块的源代码或者二进制代码。模块的二进制可执行版本,无论是可链接的库、DLL或者Java的.jar文件,都无需改动

    OCP设计

    那么如何在不改动源代码的情况下去修改它的行为呢?

    关键是抽象,可以使用STRATEGY模式和Template Method模式对代码进行重构,这个可以放在以后再学习,先大概了解一下。

    OCP缺点及解决办法

    事实证明,无论模块是多么的封闭,都会存在一些无法封闭的变化。解决这些变化的办法就是依靠经验(大多数情况下都是错误的)。那么如何解决呢?

    • 出现了变化就创建抽象来隔离以后的同类变化
    • 刺激变化(使用测试驱动开发可以帮助我们)

    结论

    在许多方面,OCP都是面向对象设计的核心所在。遵循这个原则可以带来面向对象技术所声称的巨大好处(也就是,灵活性、可重用性、以及可维护性)。然而,并不是说只要使用一种面向对象语言就是遵循了这个原则。对于应用程序中的每个部分都肆意地进行抽象同样不是一个好主意。正确的做法是,开发人员应该仅仅对程序中呈现频繁变化的那些部分作出抽象。拒绝不成熟的抽象和抽象本身一样重要。

    里氏替换原则(LSP)

    派生类型必须能够替换掉他们的基类型

    为什么需要LSP?

    在面向对象中,最主要的一个特征是继承,继承提供了机制让派生类可以使用基类中的属性和方法,这是通过在基类型里封装通用的数据和行为来实现的。那么如何更好的使用继承就是LSP所解决的。具体原则如下:

    如果对于每个类型S的对象o1,都存在一个类型T的对象o2,使得在所有针对T编写的程序P中,用o1替换o2后,程序P行为功能不变,则S是T的子类型。

    举例(长方形和正方形)

    首先定义一个长方形,

    class Rectangle
    {
        //属性
        private width;
        private height;
        
        //方法
        public function getWidth();
        public function setWidth();
        public function getHeight();
        public function setHeight();
    } 

    假如说这个程序运行在很多地方。假如有一天,要求添加操作正方形的功能。那么正方形和长方形之间满足IS-A关系,那么按照我们经常说的,继承就是IS-A的关系,那么正方形继承长方形。那么问题来了

    1. 正方形的宽和高是一样的,那么宽改变的时候,高也可以改变。 当然可以通过修改长方形中的代码来解决,但是这样就违反了OCP原则。
    2. 就算解决了上面那个问题,假如有下面这个函数

       void g(Rectangle& r)
       {
           r.setWidth(4);  
           r.setHeight(5);
           assert(r.Area() == 20);
       }

      那么很明显是错的。编写g和Rectangle类的人都没错,错的是Square类从Rectangle类继承。

    由以上的这个例子来讲,Square和Rectangle这个显然合理的模型为什么会有问题?

    对不是g函数的编写者来说,正方形可以是长方形,但是从g函数的编写者非角度来说,这个是错误的。因为对于函数g的编写者来说,Square和Rectangle的行为方式不同。对象的行为方式才是软件真正关注的问题。

    LSP让我们得出了一个非常重要的结论:一个模型,如果孤立地看,并不具有真正意义上的有效性。模型的有效性只能通过他的客户程序来表现。

    如何更好的使用LSP

    更多的假设

    在考虑一个模型的设计是否恰当的时候,不能完全独立的来看这个解决方案,必须要根据该设计的使用者所做出的合理假设来审视它。(又多了一个使用单元测试的理由)。但是大多数这样的假设都很难预测。通常的做法是,只预测那些明显的违反LSP的情况,其他的直到出现相关的脆弱性的时候再去处理。

    基于契约设计(DBC)

    这项技术可以解决“合理假设”的问题。具体来说,使用DBC,类的编写者显示的规定对该类的契约。客户代码的编写者可以通过该契约获得可以依赖的行为方式。契约是通过为每个方法声明的前置条件和后置条件来指定的。要使一个方法得以执行,前置条件必须要为真。执行完毕后,该方法要保证后置条件为真。

    上一个例子,setWidth(double w)的后置条件可以看做

    1. width == w
    2. height == old.height

    很显然,Square类并不能满足这个后置条件。DBC的前置条件和后置条件如下所示:

    再重新声明派生类中的程序时,只能使用相等或者更弱的前置条件来替换原始的前置条件,只能使用相等或者更强的后置条件来替换原始的后置条件。

    总结

    • LSP并不是真正的和继承有关,而是行为兼容性。(能用组合就尽量别用继承)

    • OCP是OOD中很多说法的核心。如果这个原则应用的有效,应用程序就会具有更多的可维护性、可重用性以及健壮性。LSP是使OCP成为可能的主要原则之一。正是子类型的可替换性才使得使用基类类型的模块在无须修改的情况下就可以扩展。这种可替换性必须是开发人员可以隐形依赖的东西。因此,如果没有显式地强制基类类型的契约,那么代码就必须良好地并且明显地表达出这一点。

    • 术语“IS-A”的含义过于宽泛以至于不能作为子类型的定义,子类型的正确定义应该是“可替换的”,这里的可替换性可以通过显式地或者隐式的契约来定义

    依赖倒置原则(DIP) 写的很好,请点击

    a. 高层模块不应该依赖于底层模块,二者都应该依赖于抽象。
    b. 抽象不应该依赖于细节,细节应该依赖于抽象。

    为什么要使用DIP

    在上文说到了面向对象类关系,依赖关系是耦合性最强的。使用该原则可以达到解耦的目的。

    什么是抽象

    一个简单但非常有效的对于DIP的解释,是一个简单的启发式规则:“依赖于抽象”。这是一个简单的陈述,该启发式规则建议不应该依赖于具体类——也就是说,程序中的所有的依赖关系都应该终止于抽象类或者接口。依据这个启发式,可得:

    • 任何变量都不应该持有一个指向具体类的指针或者引用
    • 任何类都不应该从具体类中派生
    • 任何方法都不应该覆盖他的任何基类中已经实现了的方法

    但是如果是稳定类的话,就相当于抽象,如PHP中的大多数类,抽象并不一定是形式上是抽象的,而是内容是抽象的。

    举个例子

     <?php
    
    //测试依赖倒置原则
    
    Interface readInterface{
        public function read();
    }
    
    class readPaper implements readInterface{
        public function read(){
            echo "this is paper reader";
        }
    }
    
    class readTest implements readInterface{
        public function read(){
            echo "this is test reader";
        }
    }
    
    class person{
        public $read;
        public function __construct(readInterface $read){
            $this->read = $read;
        } 
    
        public function read(){
            $this->read->read();
        }
    }
    
    $tom = new person(new readTest());
    $tom->read();

    在这个例子中person类(调用类)依赖于抽象readInterface接口readPaper类readTest类依赖于抽象readInterface接口

    总结

    依赖倒置原则是实现许多面向对象技术所宣称的好处的基本底层机制。它的正确应用对于创建可重用的框架来说是必须的。同时他对于构建在变化面前富有弹性的代码也是非常重要的。由于抽象和细节被彼此隔离,所以代码也非常容易维护。

    接口隔离原则(ISP)

    不应该强迫客户依赖于它们不用的方法。

    为什么使用ISP

    这个原则用来处理“胖”接口所具有的缺点。接口A要同时被类B类C继承,如果接口A对于类C类B来说不是最小接口,则类B类C必须去实现他们不需要的方法。此时接口A显得太“胖”。

    解决办法

    可以使用委托模式或者将接口A进行分离,类B和类C分别与他们需要的接口建立依赖关系。也就是采用接口隔离原则。

    总结 参考

    说到这里,很多人会觉的接口隔离原则跟之前的单一职责原则很相似,其实不然。其一,单一职责原则原注重的是职责;而接口隔离原则注重对接口依赖的隔离。其二,单一职责原则主要是约束类,其次才是接口和方法,它针对的是程序中的实现和细节;而接口隔离原则主要约束接口接口,主要针对抽象,针对程序整体框架的构建。采用接口隔离原则对接口进行约束时,要注意以下几点:

    • 接口尽量小,但是要有限度。对接口进行细化可以提高程序设计灵活性是不挣的事实,但是如果过小,则会造成接口数量过多,使设计复杂化。所以一定要适度。
    • 为依赖接口的类定制服务,只暴露给调用的类它需要的方法,它不需要的方法则隐藏起来。只有专注地为一个模块提供定制服务,才能建立最小的依赖关系。
    • 提高内聚,减少对外交互。使接口用最少的方法去完成最多的事情。

    运用接口隔离原则,一定要适度,接口设计的过大或过小都不好。设计接口的时候,只有多花些时间去思考和筹划,才能准确地实践这一原则。

    转载于:https://www.cnblogs.com/qiye5757/p/9872148.html

    展开全文
  • 敏捷开发原则

    2013-09-14 21:38:46
    敏捷开发原则 1.尽早,经常性进行交付。努力在项目刚开始几周内交付一个具有基本功能系统,然后努力坚持每两周就交付一个功能渐增系统。 2.团队努力保持软件结构灵活性。这样能够欢迎需求变化...
    敏捷开发原则


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

    结论:
    它指出一个包有时候应该达到部分是可抽象的,部分是不稳定的原则
    展开全文
  • 敏捷开发-原则

    2012-07-05 13:58:02
    敏捷建模(AM)定义了一系列核心原则和辅助原则,它们为软件开发项目中建模实践奠定了基石。其中一些原则是从XP中借鉴而来,在Extreme Programming Explained中有它们详细描述。而XP中一些原则又是源于...

     敏捷建模(AM)定义了一系列的核心原则和辅助原则,它们为软件开发项目中的建模实践奠定了基石。其中一些原则是从XP中借鉴而来,在Extreme Programming Explained中有它们的详细描述。而XP中的一些原则又是源于众所周知的软件工程学。复用的思想随处可见!基本上,本文中对这些原则的阐述主要侧重于它们是如何影响着建模工作;这样,对于这些借鉴于XP的原则,我们可以从另一个角度来看待。

    核心原则

      ◆主张简单 当从事开发工作时,你应当主张最简单的解决方案就是最好的解决方案。不要过分构建 

    (overbuild)你的软件。用AM的说法就是,如果你现在并不需要这项额外功能,那就不要在模型中增加它。要有这样的勇气:你现在不必要对这个系统进行过分的建模(over-model),只要基于现有的需求进行建模,日后需求有变更时,再来重构这个系统。尽可能的保持模型的简单。

      ◆拥抱变化 需求时刻在变,人们对于需求的理解也时刻在变。项目进行中,Project stakeholder可能变化,会有新人加入,也会有旧人离开。Projectstakeholder的观点也可能变化,你努力的目标和成功标准也有可能发生变化。这就意味着随着项目的进行,项目环境也在不停的变化,因此你的开发方法必须要能够反映这种现实。

      ◆你的第二个目标是可持续性 即便你的团队已经把一个能够运转的系统交付给用户,你的项目也还可能是失败的--实现Project stakeholder的需求,其中就包括你的系统应该要有足够的鲁棒性(robust ),能够适应日后的扩展。就像Alistair Cockburn常说的,当你在进行软件开发的竞赛时,你的第二个目标就是准备下一场比赛。可持续性可能指的是系统的下一个主要发布版,或是你正在构建的系统的运转和支持。要做到这一点,你不仅仅要构建高质量的软件,还要创建足够的文档和支持材料,保证下一场比赛能有效的进行。你要考虑很多的因素,包括你现有的团队是不是还能够参加下一场的比赛,下一场比赛的环境,下一场比赛对你的组织的重要程度。简单的说,你在开发的时候,你要能想象到未来。

      ◆递增的变化 和建模相关的一个重要概念是你不用在一开始就准备好一切。实际上,你就算想这么做也不太可能。而且,你不用在模型中包容所有的细节,你只要足够的细节就够了。没有必要试图在一开始就建立一个囊括一切的模型,你只要开发一个小的模型,或是概要模型,打下一个基础,然后慢慢的改进模型,或是在不在需要的时候丢弃这个模型。这就是递增的思想。

      ◆令Stakeholder投资最大化 你的project stakeholder为了开发出满足自己需要的软件,需要投入时间、金钱、设备等各种资源。stakeholder应该可以选取最好的方式投资,也可以要求你的团队不浪费资源。并且,他们还有最后的发言权,决定要投入多少的资源。如果是这些资源是你自己的,你希望你的资源被误用吗。

      ◆有目的的建模 对于自己的artifact,例如模型、源代码、文档,很多开发人员不是担心它们是否够详细,就是担心它们是否太过详细,或担心它们是否足够正确。你不应该毫无意义的建模,应该先问问,为什么要建立这个artifact,为谁建立它。和建模有关,也许你应该更多的了解软件的某个方面,也许为了保证项目的顺利进行,你需要和高级经理交流你的方法,也许你需要创建描述系统的文档,使其他人能够操作、维护、改进系统。如果你连为什么建模,为谁建模都不清楚,你又何必继续烦恼下去呢?首先,你要确定建模的目的以及模型的受众,在此基础上,再保证模型足够正确和足够详细。一旦一个模型实现了目标,你就可以结束目前的工作,把精力转移到其它的工作上去,例如编写代码以检验模型的运作。该项原则也可适用于改变现有模型:如果你要做一些改变,也许是一个熟知的模式,你应该有做出变化的正确理由(可能是为了支持一项新的需求,或是为了重构以保证简洁)。关于该项原则的一个重要暗示是你应该要了解你的受众,即便受众是你自己也一样。例如,如果你是为维护人员建立模型,他们到底需要些什么?是厚达500页的详细文档才够呢,还是10页的工作总览就够了?你不清楚?去和他们谈谈,找出你想要的。

      ◆多种模型 开发软件需要使用多种模型,因为每种模型只能描述软件的单个方面,“要开发现今的商业应 

    用,我们该需要什么样的模型?”考虑到现今的软件的复杂性,你的建模工具箱应该要包容大量有用的技术(关于artifact的清单,可以参阅AM的建模artifact)。有一点很重要,你没有必要为一个系统开发所有的模型,而应该针对系统的具体情况,挑选一部分的模型。不同的系统使用不同部分的模型。比如,和家里的修理工作一样,每种工作不是要求你用遍工具箱里的每一个工具,而是一次使用某一件工具。又比如,你可能会比较喜欢某些工具,同样,你可会偏爱某一种模型。有多少的建模 artifact可供使用呢,如果你想要了解这方面的更多细节,我在BeRealistic About the UML中列出了UML的相关部分,如果你希望做进一步的了解,可以参阅白皮书TheObject Primer -- An Introduction to Techniques for Agile Modeling。

      ◆高质量的工作 没有人喜欢烂糟糟的工作。做这项工作的人不喜欢,是因为没有成就感;日后负责重构这项工作(因为某些原因)的人不喜欢,是因为它难以理解,难以更新;最终用户不喜欢,是因为它太脆弱,容易出错,也不符合他们的期望。

      ◆快速反馈 从开始采取行动,到获得行动的反馈,二者之间的时间至关紧要。和其他人一共开发模型,你的想法可以立刻获得反馈,特别是你的工作采用了共享建模技术的时候,例如白板、CRC卡片或即时贴之类的基本建模材料。和你的客户紧密工作,去了解他们的的需求,去分析这些需求,或是去开发满足他们需求的用户界面,这样,你就提供了快速反馈的机会。

      ◆软件是你的主要目标 软件开发的主要目标是以有效的方式,制造出满足project stakeholder需要的软件,而不是制造无关的文档,无关的用于管理的artifact,甚至无关的模型。任何一项活动(activity ),如果不符合这项原则,不能有助于目标实现的,都应该受到审核,甚至取消。

      ◆轻装前进 你建立一个artifact,然后决定要保留它,随着时间的流逝,这些artifact都需要维护。如果你决定保留7个模型,不论何时,一旦有变化发生(新需求的提出,原需求的更新,团队接受了一种新方法,采纳了一项新技术...),你就需要考虑变化对这7个模型产生的影响并采取相应的措施。而如果你想要保留的仅是3个模型,很明显,你实现同样的改变要花费的功夫就少多了,你的灵活性就增强了,因为你是在轻装前进。类似的,你的模型越复杂,越详细,发生的改变极可能就越难实现(每个模型都更“沉重”了些,因此维护的负担也就大了)。每次你要决定保留一个模型时,你就要权衡模型载有的信息对团队有多大的好处(所以才需要加强团队之间,团队和project stakeholder之间的沟通)。千万不要小看权衡的严重性。一个人要想过沙漠,他一定会携带地图,帽子,质地优良的鞋子,水壶。如果他带了几百加仑的水,能够想象的到的所有求生工具,一大堆有关沙漠的书籍,他还能过得去沙漠吗?同样的道理,一个开发团队决定要开发并维护一份详细的需求文档,一组详细的分析模型,再加上一组详细的架构模型,以及一组详细的设计模型,那他们很快就会发现,他们大部分的时间不是花在写源代码上,而是花在了更新文档上。

    补充原则

      ◆内容比表示更重要 一个模型有很多种的表示方法。例如,可以通过在一张纸上放置即时贴的方法来建立一个用户界面规格(基本/低精度原型)。它的表现方式可以是纸上或白板上的草图,可以是使用原型工具或编程工具建立和传统的原型,也可以是包括可视界面和文本描述的正式文档。有一点很有意思,一个模型并不一定就是文档。它们通常作为其它artifact的输入,例如源代码,但不必把它们处理为正式的文档,即使是使用CASE工具建立的复杂的图表,也是一样。要认识到一点,要利用建模的优点,而不要把精力花费在创建和维护文档上。

      ◆三人行必有我师你不可能完全精通某项技术,你总是有机会学习新的知识,拓展知识领域。把握住这个机会,和他人一同工作,向他人学习,试试做事的新方式,思考什么该做,什么不该做。技术的变化非常的快,现有的技术(例如Java)以难以置信的速度在改进,新的技术(例如C#.NET)也在有规律的产生。现存开发技术的改进相对会慢一些,但也在持续的改进中--计算机产业属于工业,我们已经掌握了其中的试验基本原理,但我们还在不断的研究,不断的实践,不断的改进我们对它的了解。我们工作在一个变化是家常便饭的产业中,我们必须通过训练、教育、思考、阅读、以及和他人合作,抓住每一个机会学习新的处事之道。

      ◆了解你的模型 因为你要使用多种模型,你需要了解它们的优缺点,这样才能够有效的使用它们。

      ◆了解你的工具 软件(例如作图工具、建模工具)有各种各样的特点。如果你打算使用一种建模工具,你就应当了解什么时候适合用它,什么时候不适合用它。

      ◆局部调整 你的软件开发方法要能够反映你的环境,这个环境包括组织特征,project stakeholder的特征,项目自身的特征。有可能受其影响的问题包括:你使用的建模技术(也许你的用户坚持要看到一个细节的用户界面,而不是初始草图或基本原型);你使用的工具(可能你没有数字照相机的预算,或是你已经拥有某个CASE工具的license);你遵循的软件过程(你的组织采用XP的开发过程,或是RUP,或是自己的过程)。因此你会调整你的方法,这种调整可能是针对项目的,也可能是针对个人的。例如,有些开发人员倾向于使用某一类工具,有些则不用。有些人在编码上花大力气,基本不做建模,有些则宁可在建模上多投入一些时间。

      ◆开放诚实的沟通 人们需要能够自由的提出建议,而且人们还应该能够感受到他们是自由的。建议可能是和模型有关的想法:也许是某些人提出某部分新的设计方法,或是某个需求的新的理解;建议还可能是一些坏消息,例如进度延误;或仅仅是简单的工作状况报告。开放诚实的沟通是人们能够更好的决策,因为作为决策基础的信息会更加准确。

      ◆利用好人的直觉 有时你会感觉到有什么地方出问题了,或是感觉什么地方有不一致的情况,或是某些东西感觉不是很对。其实,这种感觉很有可能就是事实。随着你的软件开发的经验的增加,你的直觉也会变得更敏锐,你的直觉下意识之间告诉你的,很可能就是你工作的关键之处。如果你的直觉告诉你一项需求是没有意义的,那你就不用投入大量的精力和用户讨论这方面的问题了。如果你的直觉告诉你有部分的架构不能满足你的需要,那就需要建立一个快速技术原型来验证你的理论。如果你的直觉告诉设计方法A要比设计方法B好,而且并没有强有力的理由支持你选择某一个方法,那就尽管选择方法A。勇气的价值就已经告诉你,如果未来证实你的直觉是错的,你也有能力来挽救这种情况。你应该有这种自信,这很重要。 


    展开全文
  • 符合敏捷开发价值观和原则的开发方式包括:极限编程(XP)、Scrum、精益软件开发(Lean Software Development)、动态系统开发方法(DSDM)、特征驱动开发(Feature Driver Development)、水晶开发(Crystal Clear)等。...
  • 敏捷开发基本要素

    2010-12-28 20:44:19
     敏捷不是一个过程,是一类过程统称,它们有一个共性,就是符合敏捷价值观,遵循敏捷的原则敏捷的价值观如下:  个体和交互 胜过 过程和工具 可以工作软件 胜过 面面俱到文档 客户合作 胜过 合同谈判...
  • 敏捷开发

    2017-05-13 23:55:53
    敏捷软件开发宣言 知乎问题:敏捷开发需要写哪些文档? 回答:作者:张恂老师 ...来源:知乎 ...太极敏捷一个基本原则敏捷开发只写有价值(business value)文档。没什么价值文档,那是浪费,你写它
  • 单一职责原则(SRP:Single responsibility principle)又称单一功能原则,面向对象五个基本原则(SOLID)之一。它规定一个类应该只有一个发生变化原因。该原则由罗伯特·C·马丁(Robert ...
  • 由于书是由英文书籍翻译,读起来会难免拗口,本次分享是由《敏捷软件开发》结合网上相关资料总结而成。瀑布模型式是最典型预见性方法,严格遵循预先计划...瀑布模型传统和敏捷开发比较敏捷开发以用户需求进化
  • 敏捷开发基本思想

    千次阅读 2006-12-03 14:52:00
    敏捷开发是由一些业界专家针对一些企业现状提出了一些让软件开发团队具有快速工作、响应变化能力价值观和原则,并于2001初成立了敏捷联盟。他们正在通过亲身实践以及帮助他人实践,揭示更好软件开发方法。通过这...
  • 五年前在学校时候被要求翻译这12条原则。当时干活基本一个人搞定一切。所以没法理解这些原则们。现在参加工作几年后有点见恨晚感觉。。。分享给刚工作同学们~ 1: Our highest priority is to satisfy the ...
  • Martin在《敏捷软件开发:原则、模式与实践(C#版)》中深入而生动地使用真实案例讲解了面向对象设计的基本原则、重要的设计模式、UML和敏捷方法。 《敏捷软件开发:原则、模式与实践(C#版)》Java版曾荣获2003年第13...
  • 对于敏捷开发的见解

    2019-10-07 16:27:57
    在读了一些介绍敏捷开发的文章之后,我将自己的理解总结了一下。 敏捷开发的核心在于灵活。 敏捷开发的四条基本的价值观是: ·个体和互动高于流程和工具。 ·工作的软件高于详尽的文档。 ·客户合作高于合同谈判。 ...
  • 敏捷开发的初始理解

    2018-05-24 17:06:49
    一,什么是敏捷开发1,敏捷开发的概念敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用...
  • 在完成了第一部分《敏捷开发》部分阅读后,第七章开始介绍敏捷设计。 在本章。作者主要介绍了敏捷设计一些基本概念。 软件正在腐化标志:僵化性:一个改动会引起很多改动,这个设计就是僵化脆弱性:一个...
  • 敏捷联盟 有那么一个联盟,他们由一批业界专家聚集在一起概括了一些可以让软件开发团队具有快速工作、...从上面4条价值引出下面12项基本原则: 我们最优先要做是通过尽早、持续交付有价值软件来使客户...
  • 1.书名:敏捷软件开发原则、模式与实践 高清版PDF(Agile Software Development) 2.非常好软件设计书,曾获13界软件开发震撼(Jolt)大奖,做软件别说不知道这个奖哈。。。。。。 3.想做软件构架师话,这...
  • 在本课程结束时,您将准备好提高敏捷开发过程效率,避免常见看板陷阱,并为您团队带来最佳工作。 以下是本 Chat 内容目录: 介绍 精益和看板 精益思维 看板原则 核心练习 看板实践 ...
  • 替换原则(Liskov Substitution Princple)是OCP的重要支撑,也是继承关系设计的基本原则。其关键在于,不能单方面的、孤立的思考设计,应多从使用者角度考虑问题。设计类结构时,应该父类与子类之间的可替换性,而...
  • 第一,它运行起来所完成工作,这是最基本的。 第二,适应变化。事物是不断发展变化,所以软件模块也要在变化中成长进步,时间在一分一秒过去,这一秒我们也许就比上一秒多了一个细胞,只有拥抱变化才能拥有...
  • 本文为敏捷软件开发 - 原则、模式与实践系列的一部分。 本文对应原书第23章 COMPOSITE模式是一个非常简单但具有深刻内涵的模式。 上图中展示了COMPOSITE模式的基本结构。图中是一个形状类层次结构。基类Shape有两个...
  • 开发的前期阶段,我们完成了一些素材点,这样就能对团队的开发速度做出一个基本的估算,越久估算的就越准确,从而有利于我们对开发进行良好的计划,并粗略的计算出开发的成本。 客户首先选出一些用户素材需要开发...
  • 敏捷开发测试

    2020-07-11 09:51:36
    敏捷开发测试 敏捷软件开发方法 极限编程(XP) 极限编程(XP)最早由 Kent Beck 提出,是一种通过某些价值、原则和开发实践来描述软件开 发敏捷方法。 极限编程还描述了 13 个基本的实践:坐在一起、全团队方式、...
  • 今天把《高效程序员的45个习惯:敏捷开发修炼之道》翻了一遍,讲的基本敏捷开发的一些原则,虽然没有焕然大悟的感觉,但定期来出来提醒自己一遍也不错,这些道理虽然简单易懂,但真正要在项目中实施起来还是很有...

空空如也

空空如也

1 2 3 4 5 ... 19
收藏数 373
精华内容 149
热门标签
关键字:

敏捷开发的基本原则