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

转载一篇有货的文章。就我经历而言，架构设计已经很难从软件开发过程中如瀑布模型般，独立成一个完整阶段。采用了渐进、迭代、原型的理念，尤其是“敏捷”的过程方式，架构设计的工作已经蔓延到软件开发的几乎整个生命周期。敏捷拥抱变化，架构设计——设计的决策，也拥抱变化，相辅相成。

另外，文中一句有着相当提醒作用的是：项目团队为交付可执行软件负责，而非严格遵循过程。给我提了个醒，敏捷在实践中，小心不要陷入教条化。呵呵，一切因需而变和利益最大化，这才是敏捷的精髓吧。

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

这篇文章由IEEE Software 杂志首发，并由InfoQ & IEEE Computer Society转载于此.

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

架构和过程

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

参考文献

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有志于为领跑者和未来软件从业者创立社区。杂志传递可信，有用，先进的软件开发讯息来确保工程师和管理者与迅速变化的科技接轨。