敏捷开发下的软件架构设计与持续优化

过往的软件开发, 往往都是由架构师将他对产品的理解,利用 UML
来体现软件的架构设计。

这种方式的问题是:因缺乏使用者与团队成员间的互动参与,使得对外并未能完整的将使用者需求,映射到软件架构中;
而对内所提供的软件架构设计文档,
对实际开发的工作,
指导意义并不大(因为,厚重的架构设计文档,便如老太婆的裹脚布般;又臭又长)。更严重的问题是,由于架构设计耗费太长的时间,如此再加上开发、测试的时间,团队往往会太晚才会发现软件架构上的重大缺陷。而由于太晚才发现软件架构上的缺陷,所以,软件架构上若需做优化,则往往需耗费惊人的人力与时间成本。

敏捷开发, 经由可视化、轻量级的 "场景树", 使得使用者与团队成员间可共同的协作, 共同的识别:

  • User Story 中的活动
  • 活动后所产生的实体对象
  • 验证实体对象的纬度
  • 识别描述实体对象的价值对象

  • 整合所有 User Stories 的 User Story 地图

所以, 开发人员可根据 “场景树”与 User Story
地图,轻易且高效的找到单元测试点并设计出有效的测试用例与测试数据。而使开发人员能在最短的时间内,将软件架构直接转换为测试代码与产品代码。使开发人员能在最短的时间内,经由单元测试的
“黑盒测试”,发现到软件架构上的缺陷。

另外,SonarQube也提供了一可持续优化产品代码(架构)的平台。

“所以,在敏捷开发中,我们真的找到了一个有效的方法,去构造一高效、健康的产品开发的生态系统;经由此生态系统,使用者与团队成员将可高效的协作,共同的设计软件架构,并在最短的时间内,发现软件架构上的缺陷并持续的优化软件架构。”

欢迎你也来试试。

时间: 2024-11-15 20:20:41

敏捷开发下的软件架构设计与持续优化的相关文章

敏捷开发下开发人员的幸福

我时常和朋友们分享着在敏捷开发下的工作经验-- 在敏捷开发下,不管你用任何的程序语言,技术,框架,敏捷实践,也不管你再牛逼, 随着客户的需求越来越多,你的系统的复杂度将呈现跳跃式的增长. "系统的复杂度,终有一天,会使你不再是个高效的工作者." "没有任何的一位老板,会满意开发人员写代码的效率的." 所以,开发人员一定要懂得,在敏捷开发下, 如何为自己创造幸福-- 相信只有自己,才能为客户创造幸福. 悲观的计划. 乐观的执行. 忠于自己的心,清楚的明白,自己所能掌控

敏捷开发下该如何正确的看待人/天这件事?

传统软件估算人天的方式, 有的使用 Functional Points, Delphi....等等. 敏捷开发, 使用数学黄金比例; 1, 2, 3, 5, 8, 13; 以各 User Stories 之间 "相对" 的复杂度, 估算各 User Stories 所需的人天. 然而, 只是改变个算法, 是毫无意义的-- 软件开发, 存在着许多的误区,使得软件开发的效率与质量无法获得提升.其中之一的误区便是:期望用各式的人/天估算方法,使得开发人员, 可凖时的交付符合预期的软件. 我时

敏捷开发下的工程思维与爱的灵魂

当带着爱去做产品开发时, 便能真正看清产品开发的本质为何? 产品使用者的行为为何? 产品使用者内心真正的需求是什么? 很遗憾的是,现代大多数的人,只有 "工程的思维",却完全丧失了 "爱的灵魂":谈起产品,往往谈的只是高档的规格.复杂的架构.先进牛逼的功能.谈起工程实践,敏捷开发,往往谈的只是浮夸脱离现实的大图(理论).深涩难理解的名词.多如牛毛的输出件. "不懂得爱自己,便使自己永远活在别人的阴影下.所以,便会搞些瞎折腾的鸟事,鸟玩意.期望藉由这些鸟事,

敏捷开发采取面向对象的设计原则

n 单一职责原则(SRP) 就一个类而言,应该仅有一个引起它变化的原因. n 开放-封闭原则(OCP) 软件实体应该是可以扩展的,但是不可修改. n Liskov替换原则(LSP) 子类型必须能够替换掉它们的基类型. n 依赖倒置原则(DIP) 抽象不应该依赖于细节.细节应该依赖于抽象. n 接口隔离原则(ISP) 不应该强迫客户依赖于它们不用的方法.接口属于客户,不属于它所在的类层次结构. n 重用发布等价原则(REP) 重用的粒度就是发布的粒度. n 共同封闭原则(CCP) 包中的所有类对于

学习敏捷开发的流程

一.什么是敏捷开发? 在软件工程的语境里,"敏捷流程"不是指某一种具体的方法论或过程,而是一系列价值观和方法论的集合. 二.敏捷开发的原则 1.  尽早并持续地交付有价值的软件以满足顾客需求. 2.  敏捷流程欢迎需求的变化, 并利用这种变化来提高用户的竞争优势. 3.  经常发布可用的软件,发布间隔可以从几周到几个月,能短则短. 4.  业务人员和开发人员在项目开发过程中应该每天共同工作. 5.  以有进取心的人为项目核心,充分支持信任他们 6.  无论团队内外,面对面的交流始终是最

内修敏捷开发心法 + 外炼持续整合招式

说好的软件质量 提升软件质量是我们一直追求的理想,但软件开发唯一不变的真理就是变,为了应付变化多端的软件开发过程,敏捷开发提倡了一种拥抱变化的软件开发理念,少说也替软件开发人员带来了不少小确幸. 这些软件开发模型与方法论,最终的目的在于软件开发管理与质量的提升,与其说质量提升倒不如说是维持一定的水平.虽然敏捷开发有很多不同的方法论 (例如 Scrum, XP 等等),但我们注意到这些方法论都一定会提到「持续整合 (Continuous Integration)」这个概念.持续整合到底是何方神圣?

敏捷团队高效的完成软件架构设计

"在敏捷开发下,如何能经由敏捷团队,高效的完成软件架构设计?" 核心的思维是: 以 "团队" 为纬度,而不再以 "产品" 为纬度进行软件架构设计.唯有如此,团队才能有效的控制.处理产品上的复杂度. 也就是说,传统上, 产品团队都仅有一个.单一的产品软件架构的塑模.这种以 "产品" 为纬度的软件架构方式, 将会使所设计的软件架构, 因过于复杂与庞大:超过团队所能理解.控制.处理的范围.而使软件架构无法建立起一致性.统一性; 某些

CI/CD持续集成/持续部署 敏捷开发

敏捷软件开发(英语:Agile software development),又称敏捷开发,是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法,是一种应对快速变化的需求的一种软件开发能力.它们的具体名称.理念.过程.术语都不尽相同,相对于"非敏捷",更强调程序员团队与业务专家之间的紧密协作.面对面的沟通(认为比书面的文档更有效).频繁交付新的软件版本.紧凑而自我组织型的团队.能够很好地适应需求变化的代码编写和团队组织方法,也更注重软件开发过程中人的作用. 1,CI/CD持续集

敏捷开发模式下的测试

敏捷开发 敏捷开发倡导的就是迭代式和增量式的开发模式,并且强调测试在开发过程中的重要性 .主要是围绕以用户为中心,以客户需求为导向的开发过程,这个过程有一个特点就是"随时有变化".虽然敏捷开发引入了灵活性,但其中的重点还是在于客户满意度.客户是敏捷过程的关键环节.如果,客户能够有所参与,并且客户了解到开发对于他们参与的欢迎,那么有助于增加客户对最终产品和开发team的信心和满意度.如果客户由于其他原因不愿意参与进来,那么选择传统的开发流程更好.敏捷开发有三个比较明显的特征:依赖客户完成