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

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