【转】敏捷开发中的架构设计
上图中，敏捷开发后软件架构设计的方式产生了变化：敏捷开发把原先软件过程前期的架构设计，分散到了整个敏捷开发软件过程中。
看到敏捷开发中分散化的架构设计，想起公司财务中的"马克威茨资产组合理论"，用马克威茨这个诺贝尔大师的理论来解释敏捷开发中的分散架构形式，却也行得通。
“马克威茨资产组合理论”中说道：可以通过分散投资使收益率不变而方差（风险）减少。通俗一点讲也就是不要把鸡蛋放在一个篮子里。资产组合分散化后，可以做到收益率不变的情况下，风险减少。
这里的风险指的是波动，也就是方差。这和软件工程中的风险有异曲同工之意，即软件工程中的风险指：需求的波动，数学化后就是需求的方差。然后可以按 照统计定理推论出，把架构设计组合化，并分散化，有益于收益率不变的情况下，减少软件风险。（中间的推导过程省略，有兴趣的朋友参考相应文献）。
如果按照资产组合理论，下面这些就是软件架构设计中的组合，把一次性软件过程前期30%（甚至更多）的架构设计，换成如下的软件架构组合：
（1）引入新需求后的架构。每个Iteration中，新需求引入前，都可以进行构思和架构。
（2）重构产生架构。先让软件运行，再重构其代码。那么软件的架构随着重构自然而然的在软件过程中产生。
（3）开发过程中的设计：以前是设计完后开发，现在是边设计边开发。
（4）其他
所以敏捷开发不是轻架构设计，而是依然注重架构设计。只不过架构的方式变化了，变得更加有效且风险更小。
2. 敏捷开发中架构设计的内容
传统的架构设计，包括架构和设计两个方面、其中设计可以包含详细设计，如详细的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）重要模块，和重要类的说明。但无需设计全部的类，和类的方法。
（5）….
而详细设计阶段，则在Code编码和UT单元测试阶段进行。这个阶段重构很重要，重构使你的软件架构和组件结构自然呈现。
所以在敏捷开发中架构设计的内容发生了变化：敏捷开发中止于架构，轻详细设计。但详细设计不是消失不见了，而是转移到了开发阶段，也即是：Code is design。这样既能拥抱变化，又规避风险，又Don't Repeat Yourself。
3. 敏捷开发中架构设计的人员
敏捷开发后，软件过程变化了，架构形式变化了，随之相应的人员的责任和需要素质也会变化。
这里不说整个软件过程中的人员角色，以及职责和能力，如组长，经理，测试人员，开发人员等。这不是说这些的地方。可以另外的文章再继续。
这里强调的是，敏捷开发架构设计变化后，对开发人员提出了更高的要求，要超越Code is Code阶段，达到Code is Design的要求。如上面我们分析，敏捷开发中架构设计内容变化后，一部分的设计职责转移到了开发人员身上。所以开发人员不仅需要是技术专家，不仅能够写很好的程序，还需要有架构设计思想和能力，能够在开发过程中不断重构出Design。
总结
架构描述的是软件本身的结构，敏捷开发描述的是制造这个软件的过程，他们二者是软件科学的两条脉络，互相影响。不管敏捷与否，架构设计依然软件中最重要之一，是软件开发人员的进阶目标。
?
?
