2006-12-03 20:47:00 zhu4068 阅读数 2230
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10391 人正在学习 去看看 CSDN讲师

课程内容概述

传统项目开发

敏捷模式开发

 

第一部分:

引言:从传统项目开发说开去……

 

软件开项目管理成功的关键

1、将商业远景正确转换为产品的开发战略

2、奉行项目管理的最基本的原则和指南

3、尊重软件开发的特性、做好开发运作流程的管理

4、做好完善的需求分析和使用方案的总结

5、制定完整的计划规范,包括使用界面、控制行为、错误信息等等的详细设计

6、制定符合实际的时间表、开发里程碑、即发行通过标准

       将功能的开发与支持使用方案连接起来

       将开发时间表用里程碑来代表

7、采用多次重复、循环渐进的方式推动开发周期的进展

8、执行严格的质量、更改控制和发行的管理

 

项目管理的十大工作在软件开发项目中的运用

1、决定项目的启动

2、制定项目的范围

3、制定项目的任务的重要性和优先顺序

4、确定具体的项目工作任务和工作单元

5、分配项目资源

6、估算完成工作任务单元的时间

7、制定项目时间表

8、计算并管理项目的费用

9、项目执行的管理

       质量管理----测试

追踪进度

项目状态通报

执行更改控制

执行风险控制

执行发行管理

10、项目的结束和收尾

 

完善的软件开发项目管理的执行顺序和工作总结

软件开发项目的工作和管理流程的总结:

确定软件开发的目标——确定项目范围——进行软件功能需求分析总结——确定功能的优先顺序——进行软件功能设计——确定工作任务——进行工作任务分解——菲裴项目开发资源——估算工作任务单元的时间——进行时间表的初步排列——计算项目的关键性——软件开发的开支预算—开发的执行—程序编写——测试——文档编辑——更改控制——软件——风险管理——外包管理——发行管理——项目结束工作

 

做好项目管理执行的关键

制定清晰的开发目的,并定出相应的优先顺序

开发团队成员的工作目的和努力方向与项目的总体目的保持一致和吻合

根据开发目的的重要性和优先权妥善的分配各项资源

确定对每项具体的开发工作的个人责任以及检验标准

对开发中可能出现的风险和依赖因素有清晰的分析和认识,并制定相应的对应策略和计划

定期沟通汇报项目的进展、保持项目进度状态的透明度

使用一致的实践规章和统一的项目管理工具

       实践规章的一致性体现在:组织、方法和工具

       统一工具的使用需要从规章开始,逐渐成为企业文化

 

软件开发的工程层面流向:

软件的开发可以分为三个独立的工作流向层面:

产品:整个软件产品或系统的总体远景目标、所需提供的功能或服务

项目:为达到产品的总体远景所进行的各个局部功能或局部开发阶段所作的开发工作任务

功能:为完成产品或系统的开发所进行的局部的功能组件或分部系统的开发任务

 

三个开发层面和流向的工作细节

产品层面:产品需求总结 产品设计规范书

项目层面:确定项目的目的和速度时间表的里程碑——确定项目的依赖因素——设定风险管理计划——项目速度的里程碑时间表——调整项目速度时间表通报项目速度状态——进行项目里程碑时间表的审核

功能层面:对功能进行优先排列——作功能开发时间的估算——将功能开发时间表于项目里程碑对应——功能开发时间表(Feature Schedule)——审核工作任务分配开发资源——功能开发工作的完成——进行工作进度的通报清楚工作进度的阻碍

 

产品的远景目标和开发里程碑:

产品远景目标、市场战略、客户利益

将远景划分为更细小的局部:

主题(Themes)

使用方案(Scenarios)——M1  M2  M3小里程碑(Mini MileStone

具体功能(Feature)——F11 F12 F13   F21 F22 F23  F31F32F33功能

 

审核和循环往复:

在每个项目的里程碑末端进行阶段性审核

同时在功能开发的层面进行短期性的不断审核

对完成的工作对照项目的目标进行评估

进行必要的时间表的调节

 

 

第二部分:

敏捷模式的出现:

敏捷模式最早是由美国的17个人喊出来的,他们号称:开发实践中那些循环往复的工作流程搞的人们疲劳和讨厌,而实际上是没有什么效率的,也就是低效的,建立在繁复的程序化的步骤中,使这个工作丧失了人的主动性,强调事务和秩序,使人的能动性大大缩减,于是他们试验以人来高效的开发,而不依附于复杂的制度规定。就像是橄榄球中十几个人肩并肩抱成一团,齐心协力抢球,在软件中引进了Scrum这个词,意义是:一段时间内,整个团队发挥能动性,齐心协力围绕一个目标而努力。因此又引入了Sprint这个词,意义是“突击”,整个团队要短时间内达到目标,完成任务。

 

软件开发中应用敏捷模式:

在三个流程层面的最后一个层面:功能层面应用敏捷模式是最适用的,不仅可以提高效率,且使管理这个过程更简易,减少了像以前的开发模式的流程化,反复循环等步骤。强调团队协作和短时间(一个时间盒,比如:30天)内突击取胜,已被证实是比较有效的开发方式。

 

如何利用敏捷模式的实践

功能层面Sprint30天的时间盒周期

对功能进行优先级排列作功能开发时间的估算——将功能开发时间表与项目里程碑对应——产品开发记录(Product BackLog)——阶段工作的记录——审核工作任务分配开发资源——功能开发工作的完成——进行工作进度的通报清楚工作进度的阻碍——阶段工作的总结

功能层面Scrum:每天的时间盒周期

审核工作任务分配开发资源——功能开发工作的完成——进行工作进度的通报清楚工作进度的阻碍

 

 

敏捷模式开发适合小团队

组成人员可以是:项目经理,开发人员,测试人员,会议记录者。其中会议记录者需要是公正的记录会议内容,做好焚烧图的标记。最好是小组外的人来担当。

开发过程如下:制定时间盒(比如:30天)来完成一项功能Feature,在开始这个Sprint时,做好估计,虽不能估计每天的进度,但起码要有一个整体的估计。就像是“滚动的波浪”,当他向你涌来的时候,你看到的只是最前面的波浪,而当他靠近你时,你会注意到它的走势,高低起伏的形状。到你眼前的时候,就可以完全看到全貌,浪花的细节。估计这个时间盒内的进度就像是看滚动的波浪,随着功能的开展,进度越来越明晰。估算应是可行的、可完成的。将整个功能划分为30个任务点,并在每天早晨召开约15分钟的会议,开发人员报告进度,会议记录者记下来,并在焚烧图上标记为完成的任务点的个数。

 

焚烧图:

横纵坐标用来表示时间盒的长度,比如30天的时间盒,它的横纵坐标长度为30。将Sprint功能分为30Scrum任务单元,在会议中根据报告的完成情况标记尚未完成的任务单元的个数。将这些点连接起来会是一条折线,会有个大体的斜率。从这个斜率可以看到照此进度下去需要多少天能完成。根据某个时间段内的变化情况可以分析进度是否正常,需要做什么调整。

称其为焚烧图,是因为这条折线很像一个火被风吹着燃烧的走迹

除了这条折线,还可以每天标示已完成的任务单元个数,标示每天进行中的任务单元个数,帮助了解进度,分析问题,调整进度

 
2018-11-06 20:52:36 luchengtao11 阅读数 163
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10391 人正在学习 去看看 CSDN讲师

第一章、敏捷实践

1、敏捷联盟宣言

  • 个体和交互胜过过程和工具
  • 可以工作的软件胜过面面俱到的文档
  • 客户合作胜过合同谈判
  • 响应变化胜过遵循计划

2、在给新的团队成员传授知识方面,最好的两份文档是代码和团队。

3、有许多的敏捷过程可供选择:SCRUM,Crystal,特征驱动软件开发,自适应软件开发,极限编程(XP)

第二章、极限编程概述

1、客户作为团队成员。

2、用户素材。就是正在进行的关于需求谈话的助记符。它是一个计划工具,客户可以使用它并根据它的优先级和估算代价来安排实现该需求的时间。

3、短交付周期。

4、验收测试,一般由自动化脚本构成,不断扩充验收测试集合,并且已经通过测试的功能不允许遭到破坏。

5、结对编程、频繁交换角色、频繁交换伴侣。(感觉有点扯淡)

6、测试驱动开发。

7、集体所有权。没有程序员对任何特定的模块或者技术单独负责。

8、持续集成。(理解为项目始终可编译通过?)

9、可持续的开发速度。XP的规则是不允许团队加班工作(扯),在版本发布前的一星期除外。

10、开放的工作空间。

11、计划游戏。计划游戏不是计划着去游戏,而是做计划是个游戏。本质是划分业务人员和开发人员之间的职责,。业务人员决定特性的重要性,开发人员决定实现一个特性所花费的代价。

12、简单的设计。考虑能够工作的最简单的事情。、

13、重构。XP团队通过经常性的代码重构来扭转这种退化。重构时在不改变代码行为的前提下,对其进行一些列小的改造,旨在改进系统结构的实践活动。重构时我们每隔一个小时或半个小时就要去做的事情。

第五章、重构

1、每一个软件模块都具有三项职责。第一职责是它运行起来所完成的功能。着也是该模块得以存在的原因。第二个职责是它要应对变化。几乎所有的模块在他们的生命周期中都要变化,开发者有责任保证这种改变应该尽可能地简单。一个难以改变的模块是拙劣的,即使能够工作,也需要对它进行修正。第三个职责是要和阅读它的人进行沟通。对该模块不熟悉的开发人员能够比较容易地阅读并理解它。一个无法进行沟通的模块也是拙劣的,同样需要对它进行修正。

2、作者认为提取出函数所增加的可读性是值得花费额外一些微小的性能开销的。然而,也许那些少许的开销存在于深深的内部循环中,这将会造成较大的性能损失。作者的建议是假设这种损失是可以忽略的,等待以后再去证明这种假设是错误的。、

第六章、一次编程实践

1、如果在设计阶段,想要设计的一个类不具有任何行为,可以先不考虑。如果我们去关注那些不仅仅只有setter和getter方法的对象的话,会更有效率。

第七章、什么是敏捷设计

1、软件项目的设计师一个抽象的概念。它和程序的概括形状、结构、以及每一个模块、类和方法的详细形状和结构有关。可以使用不同的媒介去描绘它,但是它最终体现为源代码。最后,源代码就是设计。

第八章、单一职责原则(SRP)

就一个类而言,应该仅有一个引起它变化的原因。

1、为何把两个职责分离到单独的类中呢?因为每一个职责都是变化的一个轴线。当需求变化时,该变化会反映为类的职责变化。如果一个类承担了多于一个的职责,那么引起它变化的原因就会有多个。变化的轴线仅当变化实际发生时才具有真正的意义。如果没有征兆,那么去应用SRP,或者任何其他原则都是不明智的。

2、什么是职责?在SRP中,把职责定义为“变化的原因”。

 

第九章、开放-封闭原则(OCP)

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

1、对于扩展是开放的

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

2、对于更改是关闭的

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

3、无论模块是多么的“封闭”,都会存在一些对之封闭的变化。没有对于所有的情况都贴切的模型。设计人员必须对于他设计的模块应该对哪种变化封闭做出选择。必须猜测出可能发生的变化种类,然后构造抽象来隔离那些变化。

4、开发人员应该仅仅对程序中呈现出频繁变化的那些部分做出抽象。拒绝不成熟的抽象和抽象本身一样重要

第十章、Liskov替换原则

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

1、如果新派生类的创建会导致我们改变基类,这就常常意味着设计时有缺陷的。

2、正方形和矩形的关系在软件设计当中可能没那么简单。对象的行为方式才是软件真正所关注的问题。LSP清楚地指出,OOD中IS-A关系是就行为方式而言的。

第十一章、依赖倒置原则

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

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

参考:设计模式六大原则例子(四)-- 依赖倒置原则(DIP)例子

1、依赖倒置可以应用于任何存在一个类向另一个类发消息的地方。

第十二章、接口隔离原则(ISP)

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

第十三章、Command模式和Active Object模式

1、Commond模式由一个具有唯一方法的接口组成

2、Active Object模式是一个对象维护了一个Commond对象的链表。

第十四章、Template method模式和Strategy模式:继承和委托

1、Template method模式,把通用算法放置在基类中,并通过继承在不同的具体上下文中实现该通用算法。

2、Strategy不把通用的应用算法放进一个抽象基类中,而是将它放进一个具体类A中,把通用的算法放进接口I中,从这个接口派生出具体的业务类B,然后把B对象作为参数传给A,A就可以把具体工作委托给这个接口去完成。

3、两个模式都可以用来分离高层的算法和低层的具体实现细节。都允许高层的算法独立于它的具体实现细节重用。此外,Strategy模式也允许具体实现细节独立于高层的算法重用,不过要以一些额外的负责性、内存、以及运行时间开销作为代价。

第十五章、FACADE模式和MEDIATOR模式

1、FACEDE模式为一组具有复杂且全面的对象提供一个简单且特定的接口。比如,封装java.sql包,而对外部只提供一个DB类。

2、MEDIATOR模式:用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式地相互引用,从而使其耦合松散,而且可以独立地改变它们之间的交互。参考:设计模式之中介者模式(Mediator)

第十五章、SINGLETON模式和Monostate模式

1、singletom模式,参考:C++单例模式的五种实现

2、Momostate模式,把需要实例作为static成员变量,这样即使创建了多个monostate对象,实际使用的还是同一个成员变量。

3、单例模式强制结构上的单一性,防止创建多个对象实例。monostate单态模式强调行为上的单一性。

第十六章、NULL OBJECT模式

1、比如在Employee中创建一个持有唯一NULLEmployee实例的static final变量,并重写其方法。保证即使返回无效的变量也不需要特意第判断是否为NULL。

第二十章、包的设计原则

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

2、一个包中的所有类应该是共同重用的。如果重用了包中的一个类,那么就要重用包中的所有类。

3、一个包不应该包含多个引起变化的原因。

4、在包的依赖关系中不允许存在环

5、对于任何包而言,如果期望它是可变得,就不应该让一个难以更改的包依赖于它。

6、稳定性,稳定性和变化的频率没有直接关系。XXX认为,如果某物不容易被移动,就认为它是稳定的。稳定性和更改所需要的工作量有关。

第二十一章、Factory模式

1、工厂模式允许我们只依赖于抽象接口就能创建出具体对象的实例。

 

 

 

 

2019-03-01 09:42:28 qq_38314702 阅读数 1291
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10391 人正在学习 去看看 CSDN讲师

思维导图:

软件开发模式

1.瀑布模型 2.迭代开发 3.螺旋模型 4.敏捷开发

瀑布模型

瀑布模型是最典型的预见性的方法,严格遵循预先计划的需求分析、设计、编码、集成、测试、维护的步骤顺序进行。步骤成果作为衡量进度的方法,例如需求规格,设计文档,测试计划和代码审阅等等。 瀑布式的主要的问题是它的严格分级导致的自由度降低,项目早期即作出承诺导致对后期需求的变化难以调整,代价高昂。瀑布式方法在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的。
优点:

  • 调研开发的阶段性
  • 强调早期计划及需求调查
  • 确定了何时产生可交付的产品及何时进行评审和审查
  • 强调产品测试

缺点:

  • 依赖早期进行的需求调查,不能适应需求变化
  • 流程单一,开发中的经验得不到反馈和应用于本产品的开
    发中
  • 没有反映出开发的迭代本质
  • 不包含风险评估
  • 风险往往在后期才显露,失去及早纠正机会

迭代开发

迭代模式每次只设计和实现这个产品的一部分, 逐步逐步完成的方法叫迭代开发, 每次设计和实现一个阶段叫做一个迭代. 在迭代式开发方法中,整个开发工作被组织为一系列的短小的、固定长度(如3周)的小项目,被称为一系列的迭代。每一次迭代都包括了需求分析、设计、实现与测试。采用这种方法,开发工作可以在需求被完整地确定之前启动,并在一次迭代中完成系统的一部分功能或业务逻辑的开发工作。再通过客户的反馈来细化需求,并开始新一轮的迭代。
迭代式开发的优点:
  1、降低风险
  2、得到早期用户反馈
  3、持续的测试和集成
  4、使用变更
  5、提高复用性

螺旋开发

螺旋开发:1988年,巴利·玻姆(Barry Boehm)正式发表了软件系统开发的“螺旋模型”,它将瀑布模型和快速原型模型结合起来,强调了其他模型所忽视的风险分析,特别适合于大型复杂的系统。
“螺旋模型”刚开始规模很小,当项目被定义得更好、更稳定时,逐渐展开。
“螺旋模型”的核心就在于您不需要在刚开始的时候就把所有事情都定义的清清楚楚。您轻松上阵,定义最重要的功能,实现它,然后听取客户的意见,之后再进入到下一个阶段。如此不断轮回重复,直到得到您满意的最终产品。
螺旋模型很大程度上是一种风险驱动的方法体系,因为在每个阶段之前及经常发生的循环之前,都必须首先进行风险评估。
5个步骤:

  1. 确定目标,选择方案和限制条件。
  2. 对方案风险进行评估,并能解决风险。
  3. 进行本阶段的开发和测试。
  4. 计划下一阶段。
  5. 确定进入下阶段的方法。

优点: 严格的全过程风险管理;强调各开发阶段的质量;提供机会评估项目是否有价值继续下去。
缺点: 可能难以使用户(尤其在有合同约束的情况下)相信演化方法是可控的;项目的成功依赖于风险评估专门技术,如果一个大的风险未被发现和管理,就会出现问题。

敏捷开发

敏捷方法论采用迭代/增量开发的过程模型。是一种以人为核心、迭代、循序渐进的开发方法。组织上,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。时间上,相对于传统的瀑布式开发,迭代开发把软件生命周期分成很多个小周期(一般不大于2个月,建议2周),每一次迭代都可以生成一个可运行、可验证的版本,并确保软件不断的增加新的价值。
敏捷开发由几种轻量级的软件开发方法组成。它们包括:极限编程(XP),Scrum,精益开发(LeanDevelopment)等等
步骤: 编写用户案例,架构规范,实施规划,迭代计划,代
码开发,单元测试,验收测试等等

  • 个体和交互 重于过程和工具。
  • 可以工作的软件 重于求全而完备的文档。
  • 客户协作重于合同谈判。
  • 随时应对变化重于循规蹈矩。

四者对比区别:

传统的瀑布式开发,也就是从需求到设计,从设计到编码,从编码到测试,从测试到提交大概这样的流程,要求每一个开发阶段都要做到最好。
特别是前期阶段,设计的越完美,提交后的成本损失就越少。

迭代式开发,不要求每一个阶段的任务做的都是最完美的,而是明明知道还有很多不足的地方,却偏偏不去完善它,而是把主要功能先搭建起来为目的,以最短的时间,最少的损失先完成一个“不完美的成果物”直至提交。然后再通过客户或用户的反馈信息,在这个“不完美的成果物”上逐步进行完善。

螺旋开发,很大程度上是一种风险驱动的方法体系,因为在每个阶段之前及经常发生的循环之前,都必须首先进行风险评估。

敏捷开发,相比迭代式开发两者都强调在较短的开发周期提交软件,但是,敏捷开发的周期可能更短,并且更加强调队伍中的高度协作。
敏捷方法有时候被误认为是无计划性和纪律性的方法,实际上更确切的说法是敏捷方法强调适应性而非预见性。
适应性的方法集中在快速适应现实的变化。当项目的需求起了变化,团队应该迅速适应。这个团队可能很难确切描述未来将会如何变化.

2018-03-04 00:22:36 weixin_29520137 阅读数 101
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10391 人正在学习 去看看 CSDN讲师

    极限编程(extreme Programming,简称XP),是敏捷方法中最著名的一个。

    在XP中,和第一章说的一样,也是强调客户作为团队的成员。有一个新的概念就是用户素材,其实就是对于需求的交流所记录的下来的东西。另外XP也有短的交付周期,通常小的迭代一次是两周,6次及3个月是一次大的迭代。

    此外本章还讲了结对编程,这个我个人觉得还挺有意思,两个人可以相互学习,但是我很怀疑在实际操作中真的会这么干么,时间可是金钱啊,两个人干一个活真的能行?

    验收测试,当我们完成了一个测试并且系统通过了该测试,那么之后再对软件测试时,一定要通过该测试,并且不能修改这个测试。

    本章还给出了可测试代码的定义:为了通过测试用例而编写代码。这里给出的定义也在第六章有体现,颠覆了我之前编写代码的习惯,我觉得对我还是很有帮助的。

    最后的干货其实也是最常见的,那就是不能忍受重复的代码,而消除重复代码的最好方式就是抽象

2020-01-05 19:33:58 drumdream 阅读数 6
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10391 人正在学习 去看看 CSDN讲师

《敏捷软件开发》读书笔记(1)

概述

验收测试

在开始编码之前,可以用需求意图的方式写验收测试。

测试最重要的好处是对于架构和设计的影响。为了一个模块或应用程序可测,必须要对他进行解耦合。

什么是设计

  1. 遵循敏捷实践发现问题

  2. 利用设计原则诊断问题,并且:

  3. 应用适当的设计模式解决问题

设计的坏味道

  1. 僵化性,很难改动,牵一发而动全身

  2. 脆弱性,修改很容易引入问题,而且可能是无关的概念

  3. 牢固性,和某些细节牢牢绑定,很难作为可复用组件

  4. 粘滞性,保持设计比破坏设计做起来更困难麻烦,或者环境很麻烦,一修改就要花很长时间

  5. 不必要的复杂,存在有些不必要的组成,常因为开发人员预测不存在的需求

  6. 不必要的重复,就是重复、类似逻辑的代码了

  7. 晦涩,代码难以理解,不够清晰。

设计原则:

SRP:单一职责

一个类或者组件、模块,只有一个原因让其变化。但是特别要注意,仅当变化实际发生的时候,分离变化才有实际意义,这是敏捷的做法。如果没有变化,那么使用任何原则都是不合适的。

OCP:开放封闭原则

面向对象设计的核心所在,如果一个需求要修改很多地方,比如需要switch语句增加判断分支,就打破了这个原则,而且可能需要依赖这个模块的模块全部重新编译部署。遵循这点设计,需要一定程度预测的策略,或者在发生第一次变化的时候修改为抽象。可以用合适的抽象,或者用数据驱动的方式来获取封闭性(控制代码和逻辑代码分离)。

LSP:里氏替换原则

子类必须能替换基类,而且行为不变,这里关注的是行为。通常用到instanceof的地方,可能就是明显违反这个原则的方式(回想下,我们项目里好多)。这里面提到,对于继承而言,对象的行为才能说明是IS-A的关系,比如正方形和长方形,虽然属性上是,但是行为不是。所以一个设计模型的有效性,不能完全孤立的看,必须要根据使用者做出的合理假设来审视。而合理假设是难以预测的,所以只需要在遇到明显违反LSP的时候再处理。

那么如何能保证子类不违法基类的行为假设呢?可以基于契约设计,基类声明时同时声明前置和后置条件,并且在程序中对其检查,子类保证在复写时,前置条件比基类松,后置条件比基类严。

DIP:依赖倒置原则

让高层模块独立出来,提高复用,framework层的核心设计原则即为如此。优先依赖于抽象的原则,可以让客户类来定义接口,或者单独把通用的接口独立出来,让服务类实现接口,只有客户类需要修改时,才修改接口。关键是要找出系统的内部抽象、高层策略、隐喻、核心逻辑,和具体的形式无关。这个原则是构建可重用框架的必须。

ISP:接口隔离原则

对于客户程序定义接口的时候,按照隔离原则定义,不需要关注到实现类是几个类。容易破坏原则的情况,就是一个实现类继承多个接口类,当接口类扩展时候,会污染实现类,即使在基类统一实现退化接口(比如我们项目里BasePresenter的设计,统一实现了多个接口,这样某一个接口改变的时候,所有的子类都会需要重新编译)。

不应该强迫客户依赖(或者继承)于他们不使用的方法(或者模块),这样在其他客户要求接口修改的时候,就会影响到这个程序,比如换包名,修改接口等,或者修改接口后,会带来其他模块的重新编译,也会减慢编译速度。所以更强调了接口等定义要以使用者为核心,如果是服务者为核心,就会出现服务者修改接口,迫使客户端修改或者重新编译(不过现在Java的模块化或者服务化,只要接口保持向前兼容性,可以用yaml约定接口,客户方使用yaml生成api的方式,解除服务方提供api的耦合,可以独立演进)。

有这么几种方法可以帮助客户程序隔离接口,用委托分离、多重继承(实现)。而客户端依赖的接口,最好使用依赖注入的方式,符合迪米特法则,可以解决客户端程序依赖特定服务版本的问题。

当然,不能说所有的客户端自己定义接口,让服务端被迫实现不同的客户端定义的接口,我们还应该整体上对接口进行分组,同类型功能的接口放在一起(单一职责),公共的方法每个接口都定义。这个也可以是服务端定义接口,但是接口要划分合理,不能全都放在一个类里面。

敏捷开发综述

阅读数 1

没有更多推荐了,返回首页