敏捷软件开发
2018-08-31 17:22:18 157 举报AI智能生成
敏捷软件开发是一种迭代、增量的软件开发方法，强调灵活性和客户合作。它基于四个核心价值观：个体和互动优于流程和工具；客户合作优于合同谈判；响应变化优于遵循计划；以及可用的软件优于完备的文档。敏捷开发采用短周期迭代开发，如Scrum中的每两周一个迭代周期，通过持续集成、自动化测试等技术手段快速交付高质量的软件产品。敏捷开发注重团队协作和沟通，鼓励团队成员之间的直接交流和反馈，以便更好地满足客户需求并适应不断变化的市场环境。
作者其他创作
大纲/内容
打包薪水支付系统
包的设计原则
FACTORY（工厂） 模式
薪水支付案例研究（第二部分）
气象站案例研究
COMPOSITE（组合） 模式
OBSERVER（观察者） 模式
ABSTRACT SERVER 模式、ADAPTER（适配器） 模式和BRIDGE（桥接） 模式
PROXY（代理） 模式和 STAIRWAY TO HEAVEN 模式：管理第三方API
案例研究：气象站
ETS 案例研究
VISITOR（访问者） 模式
STATE（状态） 模式
ETS 框架
敏捷开发
敏捷实践
个体和交互胜过过程和工具
可以工作的软件胜过面面俱到的文档
客户合作胜过合闻谈判
相应变化胜过遵循计划
原则
我们最优先要做的是尽早的、持续的交付有价值的软件来使客户满意
即使到了开发后期也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势
即使到了开发后期也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势
经常性地交付可以工作的软件，交付的间隔可以从几周到几个月，交付的间隔越短越好
在整个项目开发期间，业务人员和开发人员必须天天都在一起工作
围绕被激励起来的个人来构建项目。给他们提供所需的环境和支持，并信任他们能够完成工作
在团队内部，最具有效果并附有效率的传递信息的方法，就是面对面的交谈
工作的软件是首要的进度度量标准
敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度
不断地关注优秀的技能和好的设计会增强敏捷能力
简单--使未完成的工作最大化的艺术--是根本的
最好的架构、需求和设计出自于自组织的团队
每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整
结论
极限编程概述
客户作为团队成员
用户素材
短交付周期
迭代计划
发布计划
验收测试
结对编程
测试驱动的开发方法
集体所有权
持续集成
可持续的开发速度
开发的工作空间
计划游戏
简单的设计
考虑能够工作的最简单的事情
你将不需要他（目前阶段不需要它就不要考虑引入它）
一次，并且只有一次（极限编程者不能容忍重复的代码。无论在哪里发现重复的代码，他们都会消除他们）
重构
隐喻（是讲这个系统联系在一起的全局视图）
计划
初始探索
发布计划
迭代计划
任务计划
迭代
测试
测试驱动开发的方法
测试促使模块之间隔离
验收测试
重构
重构，素数产生程序
一次编程实践
敏捷设计
什么是敏捷设计
软件出了什么错
设计的臭味--腐化软件的气味
僵化性：很难对系统进行改动，因为每个改动都会迫使许多对系统其他部分的其他改动
脆弱性：对系统的改动会导致系统中和改动的地方概念上无关的许多地方出现问题
牢固性：很难解开系统的纠结，使之成为一些可在其他系统中重用的组件
粘滞性：做正确的事情比做错误的事情要困难
不必要的复杂性：设计中包很有不具任何好处的基础结构
不必要的重复：设计中包含有重复的结构，而该重复的结构可以使用单一的抽象进行统一
晦涩性：很难阅读、理解。没有很好地表现出意图
什么激发了软件的腐化
需求的变化
改动的急迫，并且改动的人对原始的设计思路不熟悉，随着改动的不断积累软件腐化
然而，不能因为设计的退化而责怪需求的变化，这是我们的设计和实践出了问题
敏捷团队不允许软件腐化
敏捷团队依靠变化来获得活力
几乎不进行预先设计
保持设计的灵活性、易于理解性
敏捷开发人员如何知道要做什么
他们遵循敏捷实践去发现问题
他们应用设计原则去诊断问题
他们应用适当的设计模式去解决问题
软件开发的这三个方面间的相互作用就是设计
保持尽可能好的设计
保持设计适当、干净
每天、每小时清洁代码
敏捷开发人员对待软件设计的态度和外科医生对到消毒过程的态度是一样的。
设计必须要保持干净、简单，并且由于源代码是设计最重要的表现，所以它同样要保持干净。职业特性要求我们，最为软件开发人员，不能忍受代码腐化。
结论：什么是敏捷设计？
敏捷设计是一个过程，不是一个事情。它是一个持续的应用原则、模式以及时间来改进软件的结构和可持续的过程。它致力于保持系统设计在任何时间都尽可能得简单、干净一以及富有表现力。
单一职责（SRP）
就一个类而言，应该仅有一个引起它变化的原因
开闭原则（OCP）
软件实体（类、模块、函数等等）应该是可以扩展的，但是不可以修改的
Liskov 替换原则（LSP）
子类型必须能够替换掉他们的基类型，并且能正确执行
依赖倒置原则（DIP）
高层模块不应该依赖于地城模块。二者都应依赖于抽象
抽象不应该依赖于细节。细节应该依赖于抽象
接口隔离原则（ISP）
不应该强迫客户依赖于他们不用的方法
薪水支付案例研究
COMMAND（命令）模式和ACTIVE OBJECT（主动获取对象） 模式
TEMPLATE METHOD（模板方法）模式和STRAEGY（策略）模式：继承与委托
FACADE（外观） 模式和 MEDIATOR（中介者） 模式
SINGLETION（单例） 模式和 MONOSTATE （单一状态）模式
NULL OBJECT（空对象）模式
薪水支付案例研究：第一次迭代开始
薪水支付案例研究：实现
0 条评论
下一页
