【IT168 专稿】

    关于敏捷开发的文章很容易给人留下这样的印象：构架并不重要，它只是偶然形成的一个晦涩的词语而已。本文则要解释的正是架构的重要作用、它在开发周期中的意义、它与开发人员的关系，以及对系统成本消耗的影响。

架构是什么？

    有一个现象非常有趣：人们都喜欢辩论有争议的观点，并且通常很难达成共识。而一旦得出清晰的概念，这些辩论要么消失，要么进入更深层的内容继续争议。在软件开发中，架构（architecture）便是这样的一个概念。

    那么，架构到底是指什么呢？根据各种显性定义与用途，架构有好几种涵义，其相互之间更多的一种补充关系，而不是冲突。Martin Flowler在《企业应用架构的模式》一书中指出以下要点：

    许多人都尝试定义“架构”这一概念，但很难成形成共识。其中有两个主要因素：一个是最高层次上的系统分解；另一个是一旦制定便难以变更的决策。

    Grady Booch在一篇博文里进一步阐述了第二个观点：

    架构就是设计，但设计不等于架构。架构代表着构成系统的重要设计决策。这里，重要性是用变化所带来的成本消耗度量的。

    与开发过程相关的正是这个应付变化的难易度。不管决策的选择是有意的或无意的、显式的或隐式的，新的决策总是意味着变化，而变化就意味着付出代价。问题是，所付出的代价是否值得这次改变？这正是区别各种架构质量的一个标准。优秀的架构可以减少决策带来的影响；而拙劣的架构则会扩大成本，放大原本可以忽略的负面影响。

敏捷的架构

    很显然变化的过程会充分暴露一个架构受到决策影响的程度。因此，从变化的角度来看，架构在敏捷开发中的作用非常明显：优秀的架构应该有优秀的响应性并支持敏捷；拙劣的架构则会对敏捷有抵触作用或负面影响。

    在清楚地了解架构的意义，以及架构的作用后，我们就能很容易地看到“我们实现了敏捷，我们不需要架构”这种说法错得有多离谱，而这种想法在实际生产中将带来多大的危害也同样显而易见。在敏捷开发中，真正不需要的是堆积如山的文档，把所有开发都排除在外的、长期盲目的基础建设，以及与开发人员及开发工作分离的所谓精英角色。虽然许多人都明白这些道理，也在实践中有所应用，但这并不是架构的真正意义。

    架构涉及到对系统做出的关键决策，以及对内部结构和开发方式的共同认识。从本质上来讲，架构代表了开发团队各成员之间的日常交流和对将来的看法；是成员互相协作与讨论工作的媒介；使团队可以掌握并使用不同的开发方式。因此，架构对敏捷开发而言不再是可有可无；它是必须的。

    如果你觉得敏捷架构或代码的敏捷性是些生僻或高深的词汇，请看看在《敏捷软件开发宣言》发行前几个世纪里敏捷与敏捷性的真实意义。通常，敏捷是一个形容词，用来形容某种属性：一种简单、快捷的属性。这个词用在架构上实在是再恰当不过。许多团队过于盲目地追求开发的“敏捷”。但其实，他们应该明白，与其一味地追求敏捷，还不如想办法实现敏捷的本来意义。