【IT168 专稿】

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

架构是什么？

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

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

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

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

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

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

敏捷的架构

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

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

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

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

设计的现在进行时

    建立敏捷架构并不只是为了更好地预测结果，许多措施不但可以简化正在进行中的工作，并且同样有长期效益。只有那些完备的代码才有清晰的表达能力；并且只有那些技术负债较少的代码才会使架构成为轻松愉快的工作环境。因此，与架构相关的过程是实现架构敏捷性必不可少的一部分。

    一直以来，大家都希望能在早期阶段完成所有的架构工作，通过大规模预先设计减少以后可能遇到的风险。想法是很好，可惜这种方式是在项目周期中对项目了解最少（或最无知）的情况下来做出最重要的决策，结果不但没有减少风险，反而使风险更多，同时还损失了对变化的响应能力——因为你已经做好计划，就得按计划做下去。

    风险应该是在开发过程中逐渐消除的。一个有反馈机制的过程有足够的机会检测不确定性、减少投机因素、标明正在出现的问题，以及纠正方向。敏捷过程中已经有了这些机制，它们对架构同样有用，就像在项目其它方面的作用一样。这里有许多技巧：

* 根据架构历史，预测系统趋势和质量，包括好的方面与不好的方面。如果有经常发生缺陷的部位，或者经常需要替换的代码的详细资料，就会使这方面的工作更简单一些。
 
* 在开发过程中明确地说明技术负债，比如把有问题的部分以有规律、易于查找的方式标记在代码中，或张贴在信息公告板上。确保这些技术问题都有一个入口，并且已经着手解决，而不仅仅是标记出来。
 
* 如果有数据表明架构有问题，比如依赖性管理不善，那就把改变这些数据作为目标。这些数据甚至可以作为构建验证指标的一部分，但要注意，不能过于依赖这些数据，因为它们只在有问题并且可以作为解决问题的参考时才有价值。一旦它们吸引了过多的精力或者已经完成它们的使命，就可以扔掉它们继续前进。

* 可以用不确定性来区分代码。如果需要在两个选项之间做一个选择，那么更应该注意，问题不是“我要选择哪一个？”而是“怎么设计才能让选择变得不重要？”将不确定性封装起来可以减少选择带来的影响，避免由于信息和情况的变化而需重新选择的窘境。

* 考虑到日程安排，不确定性也可以有创造性的应用。由于不确定性通常是由于信息不足造成的，因此不要武断地做出决策。可以将决策往后顺延，直到有足够的信息可以做出可靠的决策，当然也要避免过度拖延错过最后的可靠时机（Last Responsible Moment）以至不可收拾。

    这些技巧（包括其它技巧）可以使团队体验、采用并最终取得一个可靠的过程。架构是一个实验过程：从一个清晰的蓝图开始，然后根据新信息随时做出响应。不成熟的做法经常会忽视架构，认为一个优秀的架构会随时间发展自然生成，或者认为有了优秀的工具和积极的团队便无需架构。

    跟其它形式一样，这是一个脚踏实地的过程。如果没有这方面的认识、指引和培养，一个全副武装、积极进取的团队可能也会发现，虽然越来越善于做一些修补工作，但最终困在技术负债里，找不到无休无止修补循环的根本原因。这种缺乏可预测性的架构缺少的是概念上的完整性，正如Mary和Tom Poppendieck在《精准软件开发》一书中所说：

    概念完整性就是指系统的核心概念能够平滑、紧凑地结合为一个整体。各组件能够互相匹配、紧密合作，那么架构便能找到灵活性、可维护性、效率和响应性的完美平衡点。

    优秀的架构其价值也许并不会直接体现在商业价值上，但它可以减少实现商业价值所需的成本，而具体体现在可以减少开发过程中常见浪费资源上。