精华内容
下载资源
问答
  • 一、开发原则 S:单一职责SRP O:开放封闭原则OCP L:里氏替换原则LSP I:接口隔离法则 D:依赖倒置原则DIP 合成/聚合复用原则 迪米特法则 在软件开发中,前人对软件系统的设计和开发总结了一些原则和模式,...

     

    一、开发原则

    S:单一职责SRP

    O:开放封闭原则OCP

    L:里氏替换原则LSP

    I:接口隔离法则

    D:依赖倒置原则DIP

    合成/聚合复用原则

    迪米特法则

    在软件开发中,前人对软件系统的设计和开发总结了一些原则和模式, 不管用什么语言做开发,都将对我们系统设计和开发提供指导意义。本文主要将总结这些常见的原则和具体阐述意义。

    面向对象的基本原则(solid)是五个,但是在经常被提到的除了这五个之外还有迪米特法则和合成复用原则等,所以在常见的文章中有表示写六大或七大原则的; 除此之外我还将给出一些其它相关书籍和互联网上出现的原则;

    二、S单一职责SRP

    Single-Responsibility Principle,一个类,最好只做一件事,只有一个引起它的变化。单一职责原则可以看做是低耦合、高内聚在面向对象原则的引申,将职责定义为引起变化的原因,以提高内聚性减少引起变化的原因。

    1、定义

    一个对象应该只包含单一的职责,并且该职责被完整地封装在一个类中。(Every object should have a single responsibility, and that responsibility should be entirely encapsulated by the class.),即又定义有且仅有一个原因使类变更。

    2、原则分析

    一个类或者大到模块,小到方法,承担的职责越多,它被复用的可能性越小,而且如果一个类承担的职责过多,就相当于将这些职责耦合在一起,当其中一个职责变化时,可能会影响其他职责的运作。

    类的职责主要包括两个方面:数据职责和行为职责,数据职责通过其属性来体现,而行为职责通过其方法来体现。

    单一职责原则是实现高内聚、低耦合的指导方针,在很多代码重构手法中都能找到它的存在,它是最简单但又最难运用的原则,需要设计人员发现类的不同职责并将其分离,而发现类的多重职责需要设计人员具有较强的分析设计能力和相关重构经验。

    3、优点

    降低类的复杂性,类的职责清晰明确。比如数据职责和行为职责清晰明确;

    提高类的可读性和维护性;

    变更引起的风险减低,变更是必不可少的,如果接口的单一职责做得好,一个接口修改只对相应的类有影响,对其他接口无影响,这对系统的扩展性、维护性都有非常大的帮助。

    注意:单一职责原则提出了一个编写程序的标准,用“职责”或“变化原因”来衡量接口或类设计得是否合理,但是“职责”和“变化原因”都是没有具体标准的,一个类到底要负责那些职责?这些职责怎么细化?细化后是否都要有一个接口或类?这些都需从实际的情况考虑。因项目而异,因环境而异。

    4、例子

    SpringMVC中Entity、DAO、Service、Controller、Util等的分离。

    三、O开放封闭原则OCP

    Open - ClosedPrinciple,OCP对扩展开放,对修改关闭(设计模式的核心原则)

    1、定义

    一个软件实体(如类、模块和函数)应该对扩展开放,对修改关闭。意思是在一个系统或者模块中,对于扩展是开放的,对于修改是关闭的。一个 好的系统是在不修改源代码的情况下,可以扩展你的功能。而实现开闭原则的关键就是抽象化。

    2、原则分析

    当软件实体因需求要变化时, 尽量通过扩展已有软件实体,可以提供新的行为,以满足对软件的新的需求,而不是修改已有的代码,使变化中的软件有一定的适应性和灵活性 。已有软件模块,特别是最重要的抽象层模块不能再修改,这使变化中的软件系统有一定的稳定性和延续性。

    实现开闭原则的关键就是抽象化 :在"开-闭"原则中,不允许修改的是抽象的类或者接口,允许扩展的是具体的实现类,抽象类和接口在"开-闭"原则中扮演着极其重要的角色..即要预知可能变化的需求.又预见所有可能已知的扩展..所以在这里"抽象化"是关键!

    可变性的封闭原则:找到系统的可变因素,将它封装起来。这是对"开-闭"原则最好的实现。不要把你的可变因素放在多个类中,或者散落在程序的各个角落。你应该将可变的因素,封套起来..并且切忌不要把所用的可变因素封套在一起。最好的解决办法是,分块封套你的可变因素!避免超大类、超长类、超长方法的出现!!给你的程序增加艺术气息,将程序艺术化是我们的目标!

    3、例子

    设计模式中模板方法模式和观察者模式都是开闭原则的极好体现。

    四、L里氏替换原则LSP

    Liskov Substitution Principle,LSP:任何基类可以出现的地方,子类也可以出现;这一思想表现为对继承机制的约束规范,只有子类能够替换其基类时,才能够保证系统在运行期内识别子类,这是保证继承复用的基础。

    1、定义

    第一种定义方式相对严格:如果对每一个类型为S的对象o1,都有类型为T的对象o2,使得以T定义的所有程序P在所有的对象o1都代换成o2时,程序P的行为没有变化,那么类型S是类型T的子类型。

    第二种更容易理解的定义方式:所有引用基类(父类)的地方必须能透明地使用其子类的对象。即子类能够必须能够替换基类能够从出现的地方。子类也能在基类 的基础上新增行为。
    里氏代换原则由2008年图灵奖得主、美国第一位计算机科学女博士、麻省理工学院教授BarbaraLiskov和卡内基.梅隆大学Jeannette Wing教授于1994年提出。其原文如下:Let q(x) be a property provableabout objects x of type T. Then q(y) should be true for objects y of type Swhere S is a subtype of T. 

    2、原则分析

    讲的是基类和子类的关系,只有这种关系存在时,里氏代换原则才存在。正方形是长方形是理解里氏代换原则的经典例子。

    里氏代换原则可以通俗表述为:在软件中如果能够使用基类对象,那么一定能够使用其子类对象。把基类都替换成它的子类,程序将不会产生任何错误和异常,反过来则不成立,如果一个软件实体使用的是一个子类的话,那么它不一定能够使用基类。

    里氏代换原则是实现开闭原则的重要方式之一,由于使用基类对象的地方都可以使用子类对象,因此在程序中尽量使用基类类型来对对象进行定义,而在运行时再确定其子类类型,用子类对象来替换父类对象。

    五、I接口隔离法则

    (Interface Segregation Principle,ISL):客户端不应该依赖那些它不需要的接口。(这个法则与迪米特法则是相通的)

    1、定义

    客户端不应该依赖那些它不需要的接口。

    另一种定义方法:一旦一个接口太大,则需要将它分割成一些更细小的接口,使用该接口的客户端仅需知道与之相关的方法即可。
    注意,在该定义中的接口指的是所定义的方法。例如外面调用某个类的public方法。这个方法对外就是接口。

    2、原则分析:

    (1)接口隔离原则是指使用多个专门的接口,而不使用单一的总接口。每一个接口应该承担一种相对独立的角色,不多不少,不干不该干的事,该干的事都要干。
    • 一个接口就只代表一个角色,每个角色都有它特定的一个接口,此时这个原则可以叫做“角色隔离原则”。
    • 接口仅仅提供客户端需要的行为,即所需的方法,客户端不需要的行为则隐藏起来,应当为客户端提供尽可能小的单独的接口,而不要提供大的总接口。
    (2)使用接口隔离原则拆分接口时,首先必须满足单一职责原则,将一组相关的操作定义在一个接口中,且在满足高内聚的前提下,接口中的方法越少越好。
    (3)可以在进行系统设计时采用定制服务的方式,即为不同的客户端提供宽窄不同的接口,只提供用户需要的行为,而隐藏用户不需要的行为。

    六、D依赖倒置原则DIP

    Dependency-Inversion Principle 要依赖抽象,而不要依赖具体的实现, 具体而言就是高层模块不依赖于底层模块,二者共同依赖于抽象。抽象不依赖于具体,具体依赖于抽象。

    1、定义

    高层模块不应该依赖低层模块,它们都应该依赖抽象。抽象不应该依赖于细节,细节应该依赖于抽象。简单的说,依赖倒置原则要求客户端依赖于抽象耦合。原则表述:

    (1)抽象不应当依赖于细节;细节应当依赖于抽象;

    (2)要针对接口编程,不针对实现编程。

    2、原则分析

    (1)如果说开闭原则是面向对象设计的目标,依赖倒转原则是到达面向设计"开闭"原则的手段..如果要达到最好的"开闭"原则,就要尽量的遵守依赖倒转原则. 可以说依赖倒转原则是对"抽象化"的最好规范! 我个人感觉,依赖倒转原则也是里氏代换原则的补充..你理解了里氏代换原则,再来理解依赖倒转原则应该是很容易的。

    (2)依赖倒转原则的常用实现方式之一是在代码中使用抽象类,而将具体类放在配置文件中。

    (3)类之间的耦合:零耦合关系,具体耦合关系,抽象耦合关系。依赖倒转原则要求客户端依赖于抽象耦合,以抽象方式耦合是依赖倒转原则的关键。

    3、例子1

    理解这个依赖倒置,首先我们需要明白依赖在面向对象设计的概念:
    依赖关系(Dependency):是一种使用关系,特定事物的改变有可能会影响到使用该事物的其他事物,在需要表示一个事物使用另一个事物时使用依赖关系。(假设A类的变化引起了B类的变化,则说名B类依赖于A类。)大多数情况下,依赖关系体现在某个类的方法使用另一个类的对象作为参数。在UML中,依赖关系用带箭头的虚线表示,由依赖的一方指向被依赖的一方。

    4、例子2

    某系统提供一个数据转换模块,可以将来自不同数据源的数据转换成多种格式,如可以转换来自数据库的数据(DatabaseSource)、也可以转换来自文本文件的数据(TextSource),转换后的格式可以是XML文件(XMLTransformer)、也可以是XLS文件(XLSTransformer)等。

    由于需求的变化,该系统可能需要增加新的数据源或者新的文件格式,每增加一个新的类型的数据源或者新的类型的文件格式,客户类MainClass都需要修改源代码,以便使用新的类,但违背了开闭原则。现使用依赖倒转原则对其进行重构。

    当然根据具体的情况,也可以将AbstractSource注入到AbstractStransformer,依赖注入的方式有以下三种:

    /** 
     * 依赖注入是依赖AbstractSource抽象注入的,而不是具体 
     * DatabaseSource 
     * 
     */  
    abstract class AbstractStransformer {  
        private AbstractSource source;   
        /** 
         * 构造注入(Constructor Injection):通过构造函数注入实例变量。 
         */  
        public void AbstractStransformer(AbstractSource source){  
            this.source = source;           
        }  
        /**      
         * 设值注入(Setter Injection):通过Setter方法注入实例变量。 
         * @param source : the sourceto set        
         */       
        public void setSource(AbstractSource source) {            
            this.source = source;             
        }  
        /** 
         * 接口注入(Interface Injection):通过接口方法注入实例变量。 
         * @param source 
         */  
        public void transform(AbstractSource source ) {    
            source.getSource();  
            System.out.println("Stransforming ...");    
        }      
    }

     

    展开全文
  • 敏捷开发原则

    千次阅读 2009-10-27 22:06:00
    ~学点新东西 敏捷开发原则 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):组件的抽象程度应该与其稳定程度一致。
    展开全文
  • 初识敏捷开发原则

    千次阅读 热门讨论 2014-02-15 16:19:20
    在软件开发中,我们经常会遇到类似这样的问题    我们所理解的东西无法和用户想要的达成一致,所以用户提出的要求,经过项目经理、分析师,最后到程序员的就已经被篡改的面目全非,所以,经过程序员们日以继日的...

        在软件开发中,我们经常会遇到类似这样的问题

     

        我们所理解的东西无法和用户想要的达成一致,所以用户提出的要求,经过项目经理、分析师,最后到程序员的就已经被篡改的面目全非,所以,经过程序员们日以继日的努力,终于做出来完全不是用户需要的程序了,于是我们不得不继续夜以继日的修改,终于在放弃了代码的质量、放弃了休息、加班加点的工作后,用户勉勉强强的接受了我们随时都可能奔溃的系统。

        或者我们还会 遇到另一个问题:


     

        

        第一次看到这个图的时候真是心酸,可是我们不是常常处于这种境况吗,只是我们写的是代码,而不是在挖坑,当销售部以牺牲各种签下了丧权辱国的条例之后,当产品经理大概了解了需要项目经理制定出看似争取的需求之后,就是程序员一个人在劳动的时候了,然后还要继续忍受感觉计划不合理向上反应的石沉大海,和测试部分的各种矛盾,和销售部门的各种嫌弃,就连每天加班让保安队长都建议颇多,但是干活的还是只有是自己。

        但是,程序员都是高智商的,既然就问题,就肯定有解决的方法,下面我就介绍一种解决办法——敏捷开发(agile development)。

     

    敏捷开发简介

      敏捷开发(agiledevelopment)

        是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。简言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。

      敏捷的组成

        它们包括:极限编程(XP),Scrum,精益开发(Lean Development),动态系统开发方法(DSDM),特征驱动开发(Feature Driver Development),水晶开发(Cristal Clear)等等

       

      和其他开发对比

        我们知道软件开发模型有很多,比如:

        瀑布式

        它首先是由Royce提出,该模式由于酷似瀑布闻名。在该模式中首先确定需求,然后拟定规格说明,在通过验证后方可进入计划阶段。因此,瀑布模式中至关重要的一点是只有当一个阶段的文档获得认可才可以进入下一个阶段。瀑布模式通过强制性规约来确保每个阶段都能很好的完成任务,但是实际上却往往难以办到。因为整个瀑布模式几乎都是以文档驱动的,这对于非专业的用户来说是难以阅读和理解的。虽然瀑布模式有很多很好的思想可以借鉴,但是在过程能力上有天生的缺陷。

        演化模式

        它主要是针对事先不能完整定义需求的软件开发。它的方法是用户先给出待开发系统的核心需求,并且在核心需求实现后,再提出反馈以支持系统的最终设计和实现。也就是说:开发人员首先会根据用户的需求开发核心系统,然后提供给用户试用;用户试用后再提出增强系统能力的需求;最后开发人员再根据用户的反馈,实施迭代开发。实际上,这个模式可看作是重复执行的多个瀑布模式。演化模式要求开发人员把项目的产品需求分解为不同组,以便分批循环开发。但这种分组并不是随意性的,而是要根据功能的重要性及对总体设计的基础结构的影响而作出判断。

        螺旋模式:

        它是瀑布模式与演化模式相结合,并加入两者所忽略的风险分析所建立的一种软件开发模式。螺旋模式基本的做法是在瀑布模式的每一个开发阶段之前,引入非常严格的风险识别、风险分析和风险控制。直到采取了消除风险的措施之后,才开始计划下一阶段的开发工作。否则,项目就很可能被暂停。另外,如果有充足的把握判断遗留的风险已降低到一定的程度,项目管理人员还可作出决定让余下的开发工作采用另外的生命周期模式,如演化模式,瀑布模式或自定的混合模式。

           

      过程开发模式:

        它又叫混合模式或元模式,是指把几种不同模式组合成一种混合模式,它允许一个项目能沿着最有效的路径发展。因为上述的模式中都有自己独特的思想,现在的软件开发团队中很少说标准的采用那一种模式的,因为模式和实际应用还是有很大的区别的。实际上,许多软件开发团队都是在使用几种不同的开发方法组成他们自己的混合模式。

           

        最后,我们来总结一下。螺旋模式是典型的迭代式生命周期模式,而RUP则是近代迭代式生命周期的代表。与螺旋模式相比,RUP将风险管理放在更重要的地位。最新的迭代式生命周期模式的代表是模式驱动架构(MDA)和敏捷(Agile)软件开发。MDA模式是基于可执行规格说明的思想,是现代转换模式的代表,其核心技术是组件技术。而敏捷开发生命周期的典型代表是XP编程,是把传统的系统设计和实现由敏捷软件开发过程中的验收测试、重构和测试驱动所取代;把传统的集成和部署由敏捷软件开发中的持续集成和短周期所取代。

    具体介绍敏捷开发的过程

        敏捷开发主要包括三个角色,四个仪式,和三个物件,下面一一介绍

      三个角色


        产品负责人

        产品负责人(Product Owner):它是开发团队和客户或最终用户之间的联络点。

    •     代表产品线的利益,与Scrum Master和Scrum Team合作
    •     负责管理和确定产品记录的优先次序,角色负责产品的远景规划
    •     侧重于投资回报ReturnOf Investment

       

        Scrum Master

        Scrum专家(ScrumMaster):Scrum专家负责指导开发团队进行Scrum开发与实践,它也是开发团队与产品拥有者之间交流的联络点。

    •     为Scrum Team服务,确保每一个成员都认同Scrum价值观和遵守其游戏规则
    •     组织每天的DailyScrum会议
    •     负责保证Scrum Team的持续进展
    •     决策和免除障碍
    •     帮助Scrum Team规划Sprint计划

       

        团队

        团队成员(Team Member):即项目开发人员。

    •     自我管理,自我组织,多功能,通常由6 – 10人组成
    •     负责将ProductBacklog转化成Sprint中的工作项目
    •     所有团队成员协调,合作和完成Sprint中每一个规定的工作
    •     所有团队成员和ScrumMaster负责每一个Sprint的成功

       

      四个仪式


        Sprint计划会议


        每日站会

    •     开发团队成员召开,一般为15分钟。
    •     所有成员必须参加,每个人给全体成员汇报工作进展。
    •     更新燃尽图。
    •     每个开发成员需要向ScrumMaster汇报三个项目:
              今天完成了什么?
              遇到了障碍无法继续下去?
              明天要做什么?
    •     通过该会议,团队成员可以相互了解项目进度。

       

        Sprint评审会议

        Sprint评审会用来演示在这个Sprint中开发的产品功能给Product Owner. Produc Owner会组织

    •     这阶段的会议并且邀请相关的干系人参加。
    •     团队展示Sprint中完成的功能
    •     一般是通过现场演示的方式展现功能和架构
    •     不要太正式
    •     不需要PPT
    •     一般控制在2个小时
    •     团队成员都要参加
    •     可以邀请所有人参加

           

        Sprint回顾会议

    •     团队的定期自我检视,发现什么是好的,什么是不好的。
    •     一般控制在15-30分钟
    •     每个Sprint都要做
    •     全体参加
    •     Scrum Master
    •     产品负责人
    •     团队
    •     可能的客户或其它干系人

    Sprint回顾会议上,全体成员讨论有哪些好的做法可以启动,哪些不好的做法不能再继续下去了,哪些好的做法要继续发扬。

           

    三个物件


      产品Backlog

        一个需求的列表:

    •     一般情况使用用户故事来表示backlog条目
    •     理想情况每个需求项都对产品的客户或用户有价值
    •     Backlog条目按照商业价值排列优先级
    •     优先级由产品负责人来排列
    •     在每个Sprint结束的时候要更新优先级的排列

           

      Sprint Backlog

        将整个产品的backlog分解成Sprint Backlog,这个Sprint Backlog是按照目前的人力物力条件可以完成的。

        团队成员自己挑选任务,而不是指派任务。

        每个团队成员都可以修改Sprintbacklog,增加、删除或者修改任务。

           

      燃尽图

        燃尽图直观的反映了Sprint过程中,剩余的工作量情况,Y轴表示剩余的工作,X轴表示Sprint的时间。随着时间的消耗工作量逐渐减少,在开始的时候,由于估算上的误差或者遗漏工作量有可能呈上升态势。



    当然,知道了敏捷开发的组成部分,更要知道敏捷开发的流程,下面用一幅图来说明:




    敏捷开发的先决条件


    很多人会问,既然敏捷开发这么好,可以解决这么多的问题,为什么不是所有人所有项目都在使用敏捷开发呢,这就涉及到了实行敏捷开发的先决条件:

        一、团队有三名或以上的研发工程师;

        二、团队内有一名合适的Scrum Master。


    当团队内无法找到合适的Scrum Master时,不要轻易推行敏捷。如果你的团队是由新人组成,或者即使有资深员工但是他并不了解或认同敏捷开发的话,那么你需要等待合适的Scrum Master出现。

     

     

     

     

     

     

     


    展开全文
  • 给自己定的一些开发原则

    千次阅读 2018-04-23 09:30:28
    1。能使用基类都尽量将基类抽取出来,实体类、dao、service(包括serviceImpl)、甚至Controller、测试类都可以,避免冗余;(注意:包含查询类DTO都可以有基类) 参考项目:mybatis-springMvc-CommonMapper2。...
    1。能使用基类都尽量将基类抽取出来,实体类、dao、service(包括serviceImpl)、甚至Controller、测试类都可以,避免冗余;(注意:包含查询类DTO都可以有基类)
    参考项目: mybatis-springMvc-CommonMapper

    2。DAO如果使用springData 选择好集成的JPA父类;
    如果使用的mybatis ,尽量使用通用Mapper接口来或者自定义Mapper来作为其他Mapper接口的父接口。(推荐使用代码生成器效率更高)
    展开全文
  • 在robbin的那个贴下回了一下,问我要电子书的tx陆续有几个了,本来想通过邮件发的,但是无奈太大,一一发邮件太费神了,所以想了...《敏捷软件开发 原则、模式与实践》 Uncle Bob的名著,敏捷的经典名著,这本书比
  • 敏捷开发的经典书 内容简介 在这本书中,享誉全球的软件开发专家和软件工程大师Robert C.Martin将向您展示如何解决软件开发人员、项目经理及软件项目领导们所面临的最棘手的问题。这本综合性、实用性的敏捷开发和...
  • 我所认识的软件开发原则:封装

    千次阅读 2014-09-01 16:47:49
    这个原则普遍存在于现实生活中,在软件开发领域也始终提倡着。Java向来倡导程序封装,面向接口编程,以提高工程开发和维护效率。   说到封装,让我想起大四的一次面试经历。面试官抛出的惟一与技术有关的一个...
  • 软件开发设计原则软件开发设计原则软件开发设计原则软件开发设计原则
  • 安全开发需要注意的9大原则,为了系统的安全,我们在开发过程中必须注意系统的安全开发原则,减小开发出来的系统被攻击的风险。9大安全原则分别是1web部署原则、身份认证原则、会话管理原则、权限管理原则、敏感数据...
  • web开发后端分层原则

    千次阅读 2018-11-21 14:04:31
    第一层 controller层 侧重拆分 定义: 直面用户操作 作用: 1、用户权限校验 ...开发原则: 1、根据不同用户的不同操作进行拆分。 2、时刻摒除垃圾代码 3、适时合并相关的用户操作 第二层 service层...
  • 敏捷软件开发原则、模式与实践敏捷软件开发原则、模式与实践敏捷软件开发原则、模式与实践敏捷软件开发原则、模式与实践敏捷软件开发原则、模式与实践
  • javaWEB安全开发基本原则

    千次阅读 2019-01-14 19:49:35
    javaWEB安全开发基本原则 最小化设计 用户输入最小化,尽可能少地使用用户的输入 用户输入范围最小化,过滤参数时尽量使用白名单策略 用户权限最小化,只对用户进行所需的最少授权 输出数据字段最小化,限制数据输出...
  • 软件开发的201个原则

    2019-04-06 09:22:37
    原则,是在编程技巧、编程语言、设计模式、工具之下的最底层的东西,它是人们在几十年的软件开发过程中不断经历、提炼出来的重要经验,体系了软件设计、开发过程中的设计哲学。 随着技术和时代的发展,这些原则可能...
  • 十大开发代码原则

    万次阅读 热门讨论 2011-03-16 16:53:00
    原则是本人结合项目的实施开发编写代码情况,对多年以来带领项目实施奋战在开发一线经验的提炼与概括。这十条开发指导原则,最基本的思想是“高效,高质量的写出满足业务功能目标的代码。”每人可以结合当前项目的...
  • MySQL数据库开发的36条原则

    万次阅读 多人点赞 2019-09-02 11:48:18
    欢迎添加华为云小助手微信(微信号:HWCloud002或HWCloud003),验证通过后,输入关键字“加群”,加入华为云线上技术...这些原则主要是针对数据库开发人员,在开发过程中务必注意 总是在灾难发生后,才想起容灾...
  • 管理信息系统开发原则 1 创新原则整体性原则相关性原则动态适应性原则工程化标准化原则 简述各种开发方法的基本思想优缺点和适用范围 ? 常用的系统开发方法有结构化开发方法原型法面向对象的方法和信息工程方法等 ...
  • 作者:pengdai出处:https://www.cnblogs.com/pengdai一、开发原则S:单一职责SRPO:开放封闭原则OCPL:里氏替换原则LSPI:接口...
  • 游戏开发之设计原则

    千次阅读 2019-01-13 18:34:34
    今天和大家分享一下在制作游戏的过程中需要使用的面向对象的设计原则,也是面试中面试官常问的问题。 单一职责原则 当设计一个类时,我们很容易就会在这个类中不断增加不属于它的方法或者成员,这样会造成该类...
  • 一、面向对象设计原则内容来自《敏捷开发原则、模式与实例》 SRP单一职责原则(Single Responsibility Principle): 就一个类而言,应该仅有一个引起它变化的原因。 OCP开放-封闭原则(Open Closure Principle...
  • 敏捷软件开发原则、模式与实践(全).pdf

    千次下载 热门讨论 2009-05-24 17:52:18
    敏捷软件开发原则、模式与实践(全) 敏捷软件开发原则、模式与实践(全)
  • 敏捷软件开发原则、模式与实践(全) 敏捷软件开发原则、模式与实践(全) 敏捷软件开发原则、模式与实践(全) 敏捷软件开发原则、模式与实践(全) 敏捷软件开发原则、模式与实践(全)
  • 敏捷软件开发+原则、模式与实践.pdf敏捷软件开发+原则、模式与实践.pdf敏捷软件开发+原则、模式与实践.pdf敏捷软件开发+原则、模式与实践.pdf
  • 软件开发有六大原则

    千次阅读 2018-11-16 10:13:17
    开闭原则和迪米特法则是最基本的两大法则     1.开闭原则 修改时执行关闭原则,扩展时执行开放原则 对增加新功能代码时,尽量保证不修改已有代码,然后将扩展的代码增加到项目中   2.里氏代换原则 其实...
  • 软件开发的七条原则

    千次阅读 2018-05-29 16:57:01
    在指定系统需求之前,在关注系统的各个功能之前,在确定硬件平台或开发过程之前,问问自己以下问题:这是否能为系统真正增加价值?如果答案是否定的,那就不要去做。所有其他原则都以这一条为先。 原则 #2:KISS...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 534,531
精华内容 213,812
关键字:

开发原则