写点什么

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

  • 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:283290

评论

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

云原生领域的一些技术展望

名白

容器 云原生 Service Mesh service

阿里+头条+腾讯等大厂Android面试题分享,神操作!

欢喜学安卓

android 程序员 面试 移动开发

在线HTML实体转字符串工具

入门小站

工具

ES6中扩展运算符的8种用法

devpoint

数组去重 ES6 扩展运算符

Rust从0到1-Cargo-自定义构建

rust build cargo 构建

「项目管理100问」之一篇优秀的周报是怎样炼成的?

万事ONES

项目 周报 ONES

“懂行人”合力共建“强富美高”数字经济助力千载金陵的数字一跃

脑极体

Linux之tail命令

入门小站

Linux

2021最新一线大厂Java高级架构师面试题总结,上线3天获22w浏览量

Java 编程 程序员 架构 面试

流量为王时代的短视频平台如何确保内容质量?|【话题讨论】

老猿Python

技术 内容审核 流量为王 负能量

Go 学习笔记之 命名

架构精进之路

Go 语言 7月日更

08 | 指针系列(二):记住,指针变量也是变量

Nydia

【LeetCode】雪糕的最大数量Java题解

Albert

算法 LeetCode 7月日更

Redisson 分布式锁源码 01:可重入锁加锁

程序员小航

Java redis 源码 分布式锁 redisson

推荐系统提供web服务的2种方式(二十四)

Databri_AI

算法 推荐系统 web服务

Java入门到架构-优秀书籍

Java入门到架构

Java 架构 入门 书籍

“Windows 找不到文件...”,怎么处理?

Emotion

windows 系统 找不到系统文件 windows找不到文件

极客时间-排位赛可视化工具

IT蜗壳-Tango

7月日更

.NET CORE 对象池简述

喵叔

7月日更

阿里+头条+抖音+百度+蚂蚁+京东面经,都是精髓!

欢喜学安卓

android 程序员 面试 移动开发

架构思考

zk

微信 架构 微信业务架构

李某逆道而行闭关三月,直接四杀斩获阿里/腾讯/京东/百度等大厂offer

Java架构师迁哥

话题讨论|你知道集群、分布式、微服务区别吗?

Emotion

分布式 微服务 话题讨论 集群 话题王者

【Flutter 专题】98 易忽略的【小而巧】的技术点汇总 (六)

阿策小和尚

Flutter 小菜 0 基础学习 Flutter Android 小菜鸟 7月日更

Ant蚂蚁挖矿系统软件开发资料

数据结构——树和二叉树

若尘

数据结构 二叉树

网络攻防学习笔记 Day61

穿过生命散发芬芳

网络攻防 7月日更

PowerShell 数组

耳东@Erdong

PowerShell 7月日更

(VMware)ubuntu 环境下搭建 docker 镜像私服

逸少

Docker 镜像仓库

对象存储手把手教一 | 用户数据访问控制管理ACL

QingStor分布式存储

云原生 对象存储 分布式存储

多项目并行,项目经理如何有效管理项目进度?

万事ONES

研发管理工具 ONES 项目经理 项目管理工具

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