软件架构---敏捷和架构的关系

实施敏捷方法和设计企业架构之间似乎总是存在某种冲突。

从表面上看，敏捷开发强调随着对业务领域的深入理解，逐步调整设计和计划。

架构设计则要求建立起技术架构（technology stack）。它可以满足质量属性（quality attributes），也可以向感兴趣的利益关系人进行展示，作为一种沟通的途径。

通俗来举个例子，出去旅游，敏捷开发则是走一步看一步，看到哪好玩就去哪玩，而架构则是先考虑好各种因素，选择一条最优的路线出行。

然而敏捷开发是一种软件过程方法和工具，敏捷开发本身并不能代表架构设计。这就好比建筑架构设计和建筑工程管理之间的差别一样，两者是建筑的两个方面。相同的软件行业也是类似的情况，软件架构设计描述的是事物本身，而敏捷开发描述的是创建这个事物的过程。所以敏捷开发和架构是没有直接替代关系的两个范畴。

敏捷 Architect网站也给出了一些具体的建议：

敏捷开发方法试图改善软件开发过程，使得我们可以更频繁地、更快地交付有效的解决方案。然而，尽管存在着一些成功案例，大型企业和项目在采纳敏捷上还是非常缓慢。其中一个原因是，很多敏捷方法被认为在架构方面比较弱，与复杂企业环境中交付大型系统的现实完全脱节。同时，许多架构流程被视为缓慢、笨拙和官僚。他们将从一个更敏捷的方法中受益。本网站通过把敏捷带给架构和把架构带入敏捷，来找出解决这一困境的方法。

该网站讨论了敏捷架构师的角色和一些敏捷架构的原则。

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

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

　　敏捷的要素是响应性、不断学习和充分。敏捷表现为软件及其开发过程的可持续和高质量，非持续的低质量开发有悖于敏捷。敏捷宣言中写道“对卓越技术和良好设计的持续关注有益于敏捷”，这为架构指明了敏捷开发中扮演的角色——无需大量预先设计。

敏捷开发后软件架构设计的方式产生了变化：敏捷开发把原先软件过程前期的架构设计，分散到了整个敏捷开发软件过程中。

敏捷开发中架构设计的内容

　　传统的架构设计，包括架构和设计两个方面、其中设计可以包含详细设计，如详细的UML图（详细的类图，顺序图等），详细的API设计以及接口描述，存储层数据库表字段设计等等。

出于下面两个方面的考虑，敏捷开发不适合这种架构设计内容：

　　（1）在当今的快速变化的社会中，业务需求和技术也都快速变化着，在软件过程前期花费30%（甚至更多）的时间进行架构设计，要么开发出来的软件不符合市场需求，要么就是一旦需求变动，造成较大的改动成本。如，作者了解的一个电子商务产品，当前所做的功能都是两年前规划设计的，而且如有新需求发生，需要下个版本才会采纳，导致整个产品脱离市场和客户的需求。

　　（2）架构设计包含两个方面，一是：架构，二是：设计。其中设计中的详细设计需要大量的时间，包含详细的流程，API，数据结构等设计。但软件开发阶段的Code编码阶段，同样蕴含了很多详细设计的内容，所以二者之间存在着Repeat Yourself的情况。换句话说，现在敏捷开发提倡Code is design，而以前是Design is code。但问题是，软件开发人员维护一套Design，外加一套Code，不堪重负，效率低。所以，现在是Code is Design盛行，敏捷盛行。

基于这两种原因，敏捷中将传统的架构设计分成：架构 + 设计：

（1）敏捷开发的架构保留架构部分

（2）转移设计到Code编码阶段、重构阶段、Unit Test阶段等。

分离后，敏捷开发中的架构就轻装上阵，内容可以包括：

（1）软件的架构层次，层次化是软件产品架构中很重要的一部分。

（2）产品和技术选型

（3）各个组件的结构，以及的关系

（4）重要模块，和重要类的说明。但无需设计全部的类，和类的方法。