写点什么

敏捷和架构设计分道而行,又最终拥抱彼此成为朋友

  • 2016-10-12
  • 本文字数:2169 字

    阅读完需:约 7 分钟

《程序员必读之软件架构》一书的作者 Simon Brown 说:由于对敏捷宣言的误解,人们认为不再有必要定义软件架构或者做软件设计。很多软件开发者没有足够的工具箱,而且软件业界缺乏共同的软件架构词汇表。一个好的架构使得敏捷性成为可能,因为足够的预先设计,为设定未来的方向打下稳固的基础。

SwanseaCon 2016 的开幕演讲上,Brown 谈了敏捷和架构设计是如何分道而行,又是如何最终成为好朋友。SwanSeaCon 016 在南威尔士举行,是第二届敏捷开发和软件技艺会议,参与的人包括软件开发者、软件架构师、项目经理、分析师和咨询师。InfoQ 通过问 & 答、总结和文章的方式全程报道了该会议。

Brown 说,瀑布模型目标是优化那些你可以在早期获知的事情。开发前期花费的时间能够有效降低后期的开销。作为示例,他提到了结构化系统分析和设计方法 (SSADM),一个基于瀑布模型的软件开发方法。它采用系统管理的概念为软件设计提供端到端的生命周期管理。Brown 也提到了统一软件管理流程(RUP),一个增量迭代的框架。采用 RUP 时,应该根据实际项目做定制,但是没有人这么做,所以大家认为 RUP 流程太大了。

瀑布模型的主要问题是反馈周期太长。瀑布模型的结构化和严谨性有助于开发一个高质量的产品,但是如果没有及时的反馈,会带来开发错误产品的风险。
敏捷宣言声明了流程和工具重要,而个人和交互的价值更高。但是很多人错误地解读了敏捷宣言,认为不再需要流程。敏捷宣言也声明了“有效的软件产品比全面的文档重要”,这也使得人们认为没有必要做架构和软件设计。Brown 说,这导致了敏捷和架构设计的冲突。

第一个冲突是关于团队的结构,问题是我们是否需要一个专职的软件架构师,或者团队中的每一个人都是架构师?敏捷宣言第 11 条声明了“最好的架构、需求和设计源于自组织的团队”。Brown 说,好消息是声明里确实提到了架构和设计。他看到过成功地把架构师的角色延展开的团队,但是也看到了没有人负责架构和设计的团队,在这样的团队里,每个人都认为架构设计是别人的事情。

第二个冲突与流程有关。Brown 说,历史上,曾经出现过预先进行大量设计(BDUF)的趋势,人们尝试理解所有的事情,从而预先绘制一本蓝图。人们想知道敏捷是否允许进行一些预先设计。进化论设计方法尝试提供一套可以做一些预先设计的解决方案,但是当架构设计不正确的时候,软件修改变得很困难,重构的开销巨大。Brown 说,如果一开始就着手构建,核心功能模块更可能运行到最好的状态。

Brown 不赞同测试驱动开发(TDD)不需要架构的观点。他建议预先确定架构,这样 TDD 可以在设定的界限内工作。同时,Brown 强烈反对在“最后负责任时刻”才确定架构,因为这很可能被解读为“任何时候都不要做决定”。

Brown 说,为了解决架构方面的问题,我们需要理解敏捷的真正意义。他提出的核心定义是:

快速行动,拥抱变化,经常发布软件,获取反馈。

敏捷是一种轻量级的软件交付方法,它基于持续提高的想法和文化。Brown 说,真正地做敏捷,而不是形式上敏捷,这很重要。但是敏捷宣言的措辞容易让人误解,“x 胜于 y”的表述常常被错误地解读为 y 不重要。

宣言第九条声明“持续关注技术上的卓越和优秀的设计增强了敏捷性”。Brown 说,一个好的架构使得敏捷成为可能。按照他的说法,敏捷性是一个“非功能的”,或者说是“质量”的需求。采用敏捷,你需要平衡多快地行动,以及多高的软件质量。

Brown 质疑是否有软件设计复兴,因为纪律化的敏捷交付(DSDM)和大规模敏捷框架(SAF)等方法都有软件设计的元素在里面。他说:

这不是说要创造一个完美的最终状态、框架、或者一个完备的架构。你需要为团队以及你所构建的东西设定一个起点,使得你们可以在正确的方向上,作为一个团队合力前进。

精益和敏捷都以增值和移除浪费为目标。定义一个起点是很价值的,你需要适当的预先设计打造坚固的基础,设定正确的方向。

Brown 说维基百科中定义的软件技艺太专注于代码。很多软件开发者没有足够的工具箱。有许多书写软件文档的方法,但是人们常常不知道它们。如果你问他们是如何进行软件设计的,他们说一些诸如“我们使用白板”,以及“我们画一个方框代表组件”。他所经历的是很多人不知道怎么组件化,用什么标准分解组件,例如有的人没有听说过类- 责任- 协作(CRC)。

Brown 说:“在同一方向上快速行动,需要良好的沟通和交流”。软件业界缺乏软件架构方面的共同的词汇表。软件开发应该被看成是一种工程学规范。他提到了 Mary Shaw 的关于通向软件工程学规范的进程的演讲 (包括在 InfoQ 的评论文章软件 - 有否成为一门“工程学”中)。Shaw 总结了软件开发成为工程学所需要做的事情:

某种意义上说,我们是一种工程学规范,但是我们的实践还不能持续地达到一定的水准,以确保计算系统的质量能够满足工程学相关的社会契约。我们需要继续把科学的、已经被纂写好的知识引进到软件设计和分析领域中。

Brown 说,尽管敏捷和架构设计在过去的一段时间里曾经分道而行,但是在 15 年之后,他们终于又成为了朋友。他说:“让我们不要忽略过去的经验,而是从中学习”。

查看英文原文: How Agile and Architecture Parted and Finally Became Friends


感谢夏雪对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ @丁晓昀),微信(微信号: InfoQChina )关注我们。

2016-10-12 19:002509

评论

发布
暂无评论
发现更多内容

云原生多云应用利器 -- Karmada 调度器

Daocloud 道客

Kubernetes 云原生 开源软件 Karmada

Kafka中指定副本为Leader的三种实现方式

石臻臻的杂货铺

kafka 运维

IOS技术分享| anyLive 开源项目

anyRTC开发者

ios 音视频 移动开发 视频直播 开源demo

DM 中 relay log 性能优化实践丨TiDB 工具分享

PingCAP

EMQ 正式成为 OASIS 最高级别成员,主导推进物联网协议标准化应用

EMQ映云科技

开源 物联网 ibm mqtt OASIS

云原生网络利器--Cilium 总览

Daocloud 道客

ebpf cilium 云原生网络 容器网络方案

会声会影2022脸部索引功能详解

懒得勤快

web前端培训:Vue3 调度系统的深度剖析

@零度

Vue 前端开发

2022年1月娱乐直播行业用户洞察:行业格局稳定,内容运营精细化

易观分析

一文全面掌握大数据关联与汇聚

云智慧AIOps社区

redis Clickhouse flink sql 大数据开发

微服务身份认证需求下的私钥托管痛点与破局

全象云低代码

微服务 低代码 身份认证 鉴权 密钥

《重构 JavaScript》读后感和部分摘录

道道里

前端 测试 重构

智汇华云 | Kubernetes多集群管理方案kubefed原理解析

华云数据

云计算 华云数据 虚拟云

上手体验!如何借助龙蜥实验室快速部署 Web 应用?

OpenAnolis小助手

开源 国产操作系统 web服务器

如何获取 Docker 容器的 IP 地址

AlwaysBeta

Docker 容器

脱颖而出!OceanBase 入选 2021“科创中国”开源创新榜单

OceanBase 数据库

数据库 分布式 OceanBase 开源 科创中国

2022年数据库审计厂家就选行云管家!功能强大!

行云管家

数据库 网络安全 数据库审计

为什么需要线程池?什么是池化技术?

CRMEB

java培训:MyBatis的架构与原理分析

@零度

mybatis JAVA开发

高性能图计算系统 Plato 在 Nebula Graph 中的实践

NebulaGraph

图数据库 图计算 分布式图数据库

大数据培训:Spark高频面试题汇总

@零度

大数据 spark

《隐私计算》重磅发布,全面、系统论述数据要素安全流通价值

博文视点Broadview

检测图片中是否有二维码

逆锋起笔

android 二维码 Android端 3月月更

始于信任 忠于专业|DataPipeline收到一封来自山东城商行联盟的感谢信

DataPipeline数见科技

Web 键盘输入法应用开发指南 (3) —— 输入法事件

天择

JavaScript 键盘 输入法 3月月更

混合云管平台排名您知道吗?看这里!

行云管家

混合云 云管

【C语言】一篇速通操作符

謓泽

C语言 操作符 3月月更

数仓中长跳转问题复现及解决方案

华为云开发者联盟

寄存器 GaussDB(DWS) 长跳转 编译器O2

2022,你的团队距离持续部署还有多远?| 研发效能提升36计

阿里云云效

阿里云 云原生 持续部署 研发团队 研发

首发|Clusterpedia 0.1.0 四大重要功能

Daocloud 道客

开源项目 多云管理 K8s 多集群管理 多云资源复杂检索

从Nacos到完全自研|得物的注册中心演进之路

得物技术

架构 raft 注册中心 实例 兼容性测试

敏捷和架构设计分道而行,又最终拥抱彼此成为朋友_研发效能_Ben Linders_InfoQ精选文章