写点什么

架构与敏捷:不得不说的故事

  • 2014-05-29
  • 本文字数:3002 字

    阅读完需:约 10 分钟

这篇文章由 IEEE Software 杂志首发,并由 __InfoQ & IEEE Computer Society__ 转载于此_._

敏捷开发离不开架构?架构离不开敏捷开发?难道得出这些问题答案非要经由一场讽刺漫画般、基于根深蒂固价值观的针锋相对,而不能在二者清晰定义之上、基于开放的、推理式的对话?也许,更通俗地描述问题是回答它的良好开始:除了专注于敏捷方法之外,我们还需要广泛考虑各种开发过程?而且,与提出假设性问题相比,我们应该思考更开放、中立的问题——架构与过程之间的关系是什么?

架构和过程

架构一词常通常被定义为“系统的结构性拆分,包括模块划分、块间关联、交互机制以及系统设计的指导原则”1

尽管从技术角度看它并不正确,但这一定义却可以支持广泛的解释。它上可指与技术、代码、实际系统架设 2 几近无关的高层抽象设计,下可代与很多类、代码级细节密切相关的大而僵化的预先设计。然而,实际情况却是,这两种指代既不足以指导实际项目开发流程,又不足以为“好”架构带来必要的贡献。前者太抽象以至很难涉及具体细节;后者尚未得知相关事实就早早下了论断。因而,敏捷社区的部分人不把架构当作真实项目开发的核心要素也就不足为奇了。

相形之下,Grady Booch3 和 Martin Fowler4 共同提出了价值导向的软件架构定义。他们把架构定义为昂贵且难于改变的重大决策。Paul Dyson 和 Andy Longshaw 在架构的结构性定义之上作了指导设计决策方面的论据补充。这些定义有助于我们将架构视为功能需求、操作特性和开发者适居性等需求所对应的解决方案。

实际上,从一份手拟初稿到各项关键细节,描述软件架构少不了各类决策:有些决策恰当而明确,有些决策需要假设条件,还有些决策做时无心,事后却发现很重要。

这样看来,架构是为开发能达成一系列商业和技术目标 6 的软件系统而提供的指导性服务,以最适合于交流和分享的形式呈现;它本身并不是什么技术造物,要借纯粹的形式化描述存在。

过程可以被看作一系列问题的答案:谁在做什么?什么时间?为什么做?为谁做?每个软件开发项目都对应于一个过程,即便它并不明显:无论松散或正式,无论团队是否主动控制开发,过程都在为这些问题作答。

然而,你也可以看到,我们在项目成员、预算和规划方面做出的决定会极大地影响到架构的选择和可行性。这一结论适用范围很广:从无视最初版本的康威定律 7 指导的系统分划带来的强大影响,到技术选择和技能、预期范围、发布模式,甚至实际系统设计方面的问题。

这些影响相互依赖,再加上随时间变化这一趋势,需要过程为架构的相关切面建立清晰的决策链和直接且有意义的反馈环,从而将最新的信息融入决策,以便应对不可避免的发明或发现带来的影响。过程要为项目团队提供支持,而不是颠倒过来,项目团队是为了交付可运行软件而不是为了遵循过程。这正是敏捷过程的目标。

架构对敏捷开发而言意味着什么?

与软件社区的某些讨论相比,敏捷开发并非要求像船货崇拜那样热衷于 Scrum 或其他过程、工具和方法学,尽管我们的确看到了这一现象并认为这是个问题。敏捷的要素是响应性、不断学习和充分。敏捷表现为软件及其开发过程的可持续和高质量,非持续的低质量开发有悖于敏捷。敏捷宣言中写道“对卓越技术和良好设计的持续关注有益于敏捷”,这为架构指明了敏捷开发中扮演的角色——无需大量预先设计。

我们的朋友和同事 Jens Coldewey 做过评价,架构能促使快速行动。即便从任何敏捷的立场出发,如果一个架构因为未能很好地分析与实现目标而阻碍你做出变化的话,结果将既得不到好的过程也得不到好的架构。这样的架构不可能与开发团队一起持续提高对系统目标及实现的理解,相反会与团队及源源不断的需求唱反调。

谈到敏捷,务实的架构师有必要关注一个简单的问题:哪些架构问题会妨害团队敏捷。问题很简单,但答案既不简单也不容易,因为技术高手和设计专家需要就若干关注点进行协商。模块化与应用领域模型间的冲突、不必要的耦合、频繁的组件间交互,都有碍于程序员(对架构)的理解,推高了的构建和交付所需的时间,不利于程序员测试、做小变动和尝试。任何设计 4 中不必要的不可逆性、轻率、无结构的技术债都会带来提高成本,降低宜居性,并伤害敏捷。

架构需要从过程中得到什么?

架构从何而来?驾白鹤而来?随邮件投递?从无所不知的架构师脑海中孕育而生?抑或如魔法般神秘出现?

停下来想一想,架构只是一种知识的表达方式。软件开发作为一项知识性工作,需要学习技术、学习客户需求,学习和提出产品需求的人交流,学习从设计实践中选取最佳方案,学习合作等等。总而言之,知识源自学习,学习需要时间,而时间正是过程的组成元素。

无论是整个产品开发还是简单发布,开始时知识最少,也最无知。牢记一点,提前做完所有的重大决策的做法既不明智也不负责。另一方面,项目结束时知识积累最丰富,但践行机会却所剩无几。一言以蔽,架构希望从过程中得到学习的空间和时间,这就要求开始时不能像结束时那样盖棺定论。也可以说它是一种经验性活动,其中的每项决策都应视为假设,加以验证并使之影响下一个决策。

项目团队为交付可执行软件负责,而非严格遵循过程。

这种基于响应和学习的方法能容纳源源不断的需求。重要的是,即便很多时候看似已经明确,但需求也会由于理解、市场和政策带来的一系列稳定或不稳定的变化而变化。

在生活中,我们往往通过分类和推理来理解事物,在软件开发中,这样做也未尝不可;在生活中,我们常常意识到,错误的类别设定、截然的分划和二元论都会影响我们对事物的理解,在软件架构和敏捷中又何尝不是如此。

创造手法影响并约束创造能力;事物的重要设计特征影响并约束创造手法。架构与过程间的强联系意味着架构师需要立足于结构和技术外,思索系统开发如何按时开展。对软件本身、开发者和组织而言,根据总体规划设计的方案并不一定是最适合的。敏捷过程对环境中源源不断的发现和变化敏感。务实的架构师要清晰地认识流程的障碍,排除它们对程序员和相关干系人可能带来的挫败感,使他们紧密地围绕着架构,而非单纯地与架构合作

参考文献

  1. J. Rumbaugh, I. Jacobsen, and G. Booch, The Unified Modeling Language Reference Manual, Addison-Wesley, 1998.
  2. J. Spolsky, “ Architecture Astronauts Take Over ,” 1 May 2008.
  3. G. Booch, “ On Design ,” blog, Mar. 2006.
  4. M. Fowler, “Who Needs an Architect?,” IEEE Software, vol. 20, no. 5, 2003, pp. 11–13.
  5. P. Dyson and A. Longshaw, Architecting Enterprise Solutions, John Wiley & Sons, 2004.
  6. R. Faber, “Architects as Service Providers,”IEEE Software, vol. 27, no. 2, 2010, pp.33–40.
  7. M. Conway, “How Do Committees Invent?,”Datamation, Apr. 1968, pp. 28–31.

作者简介

Frank Buschmann 是 Siemens 科技公司的高级首席工程师,兼任系统架构和平台部门的首席架构师。他的联系方式是 frank.buschmann@siemens.com .

Kevlin Henney是软件架构,开发流程和程序技术与实践方面的独立顾问。他的联系方式是 kevlin@curbralan.com .

这篇文章由 IEEE Software杂志首发。 IEEE Software 有志于为领跑者和未来软件从业者创立社区。杂志传递可信,有用,先进的软件开发讯息来确保工程师和管理者与迅速变化的科技接轨。


感谢马国耀对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ )或者腾讯微博( @InfoQ )关注我们,并与我们的编辑和其他读者朋友交流。

2014-05-29 03:283280

评论

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

阿里云强力贡献:如何让 StarRocks 做到极速数据湖分析

StarRocks

数据库 大数据 StarRocks

Docker编排利器DockerCompose,java面试题大汇总

爱好编程进阶

Java 面试 后端开发

Linux 信号(Signal)

mazhen

Linux JVM signal Linux Kenel

星环科技春季新品发布周,4月19日-23日重磅内容等你来解锁!

星环科技

百度ToB垂类账号权限平台的设计与实践

百度Geek说

架构 后端

一键智能Mock,你值得拥有

Liam

前端 前端开发 Postman swagger web前端开发

融云猿桌派:听说女生不适合搞 IT,哈?

融云 RongCloud

Github上都在疯找的阿里内部“全栈技能修炼”终于来了,中级java工程师面试题

爱好编程进阶

Java 面试 后端开发

为什么你应该了解 Loggie

网易数帆

Go Kubernetes 云原生 日志 Loggie

Scrum基础框架,快速配置Scrum自动化场景

阿里云云效

云计算 阿里云 Scrum 敏捷开发 研发敏捷

IstioCon 2022,网易数帆六年优化经验即将揭秘

网易数帆

微服务 云原生 istio 服务网格 Service Mesh (ASM)

融云 Unity SDK 升级,专注游戏场景,更好社交体验

融云 RongCloud

架构实战营 - 第 6 期 模块三课后作业

乐邦

「架构实战营」

百度程序员开发避坑指南(Go语言篇)

百度Geek说

后端

DPDK技术系统学习一(接收,发送,arp,icmp功能测试)

Linux服务器开发

虚拟化 网络协议栈 Linux服务器开发 DPDK C++后台开发

「连接」与CRM的「中国式」关系

ToB行业头条

黑客是怎么cookie获取?钓鱼?键盘记录?

喀拉峻

网络安全 XSS

eclipse配置SVN和Maven插件,原生Java开发的路该怎么走

爱好编程进阶

Java 面试 后端开发

Excel是世界上最危险的软件?

图灵教育

Python 数据分析 Excel

新华三首发400G园区核心交换机,开启园区超宽时代

H3C-Navigator

网络 交换机 智慧园区 网络交换机

90天吃透阿里P8推荐的625页Java编程兵书技术实战,直接入职阿里定级P6

爱好编程进阶

Java 面试 后端开发

FastDFS入门,Java编程笔试题及答案

爱好编程进阶

Java 面试 后端开发

阿里云服务网格 ASM 正式发布商业化版本

阿里巴巴云原生

关于 MySQL 数据库学习的书籍有哪些值得推荐?

程序员万金游

MySQL 数据库 java 日志 MySQL 数据库 java

2021阿里总监最新整理:初级-中级-高级大厂面试真题(附答案解析

爱好编程进阶

Java 面试 后端开发

使用 Serverless Devs 插件快速部署前端应用

阿里巴巴云原生

互联网通信安全之 WebRTC 传输安全机制

融云 RongCloud

记一次Kafka写入超时问题详细分析

移动云大数据

kafka

持续进击,STI上演极致通缩模型

BlockChain先知

《数字经济全景白皮书》金融科技篇 重磅发布!

易观分析

金融科技 互联网金融

新一代态势感知系统发布——北望

H3C-Navigator

网络安全 网络 态势感知关联分析、SOC 态势感知 安全运营

架构与敏捷:不得不说的故事_研发效能_Kevlin Henney_InfoQ精选文章