剑客
关注科技互联网

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

《程序员必读之软件架构》一书的作者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
)关注我们。

分享到:更多 ()

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址