13.2.1  实践中的常见问题

在从需求工作向架构设计工作转移的环节上，我们在实践中暴露出一些问题。对于软件架构师而言，这些问题在一定程度上相当普遍，所以我们一起来解决它们。

问题一：抱怨留给架构设计的时间太短，而不是接受项目节奏普遍加快的现实。

从根本上讲，这是没有意识到软件开发所根植于的业务背景——当然，我相信或多或少也受到瀑布模型的影响。无论是对于企业业务还是个人业务，在复杂和高速变化的经济环境里，在对手云集的竞争条件下，软件系统“上马”太慢本身就潜藏着巨大风险。在《非程序员》第50期中有一篇来自Markus Völter和Jorn Bettin的论文《模型驱动软件开发模式》，其中强调新的商业应用的开发期最多不得超过9个月：

……

每三个月至少要提供可交付代码。

理想情况下，每三个月应将代码部署到产品中，并得到实际反馈。

新的商业应用的开发，必须在九个月之内“哇哇坠地”，否则就可能危及“妈妈”（开发组）或“婴儿”（应用）的生命……

问题二：认为必须详细分析所有的需求，只有这样才能设计出满足所有需求的软件架构。

有仗就打、有人讨敌骂阵就出战，这种情形在历史小说里经常见到，但往往出现在有勇无谋的武将身上。与此类似，想要将所面对的所有需求都分析一遍的软件架构师是否想过：这是否现实？在有限的时间里，将精力分散在过多的问题上，其结果往往是效果更差。

我们的策略是：关键需求决定架构，其余需求验证架构。

顺着“全面认识需求”的策略思考开去，很容易让人产生疑问：你是在说瀑布式开发吗？当然不是。我们的策略是：在架构设计期间，关键需求决定架构，其余需求验证架构。也就是说，“关键需求决定架构”和“全面认识需求”的策略是不矛盾的。

非关键需求可以用来验证架构，比如以架构方案评审的方式，从每项非关键需求的角度对架构方案进行走查。

问题三：认为软件架构必须是完美的技术解决方案。

关于这一点，Philippe Kruchten在他的论文《Common Misconceptions about Software Architecture》中明确地进行了批评，并指出架构“够用就好”：

通常，在进行系统架构设计时，时间非常关键。架构师根本没有时间去系统地研究每一种可能的解决方案，以找出最佳解决方案；而是必须快速决策，以便让软件开发工作进行下去。项目开发就像一场“战斗”，如果慢慢吞吞地研究出了最佳解决方案，只怕整场“战斗”早已结束多时了，这显然毫无意义。我经常这样描述架构师的工作：在有些事情并未完全清楚的情况下，快速做出一系列并不算完美的设计决策。架构并不是静态功能，因此无法优化至最佳——无论是设计约束，还是棘手问题，都不会长时间不变而“等”你找到最佳方案。架构不是要完美，而是要足够满意。（Usually, time is of the essence when designing system architectures. The architects have no latitude to systematically study all possible solution paths and their combinations in order to come up with the optimal solution; they must rapidly make decisions to allow work to proceed. There is no point in coming up with the ideal solution after the battle is lost. I often describe the life of a software architect as a long and rapid succession of suboptimal design decisions taken partly in the dark. It is not a static function that we are optimizing anyway. Neither the constraints nor any parts of the problem are static enough for long enough to approach anything "optimal". Architecture is not about the optimal, or ideal; it is about the adequate, or satisfactory.）

13.2.2  关键需求决定架构

采用关键需求决定架构的方法，其好处有二：一曰防守，二曰进攻。

说到“防守”，多少有些“不得不为”的意味。的确如此。

Ÿ   一方面，把所有需求统统确定下来之后再开始下游活动是不现实的。需求来自于实践的需要，而实践是发展的，所以“确定的需求”只能是暂时的。于是，我们不得不在“部分需求已确定”的情况下进行架构设计。

Ÿ   另一方面，项目何时交付往往是由客户业务的需要决定的，或者是由市场形势决定的，这使得项目工期成了不可改变的“外部限制”（上市时间是一种非功能需求）。时间有限，我们不得不在就项目的业务目标及核心需求达成共识之后开始架构设计，而这时需求并未完全清晰化。

至于“进攻”就是对期望目标的“主动追求”了。我们希望追求的目标有两个：

Ÿ   第一，用有限的精力深入分析最为重要的需求。人的思维能力所能应对的复杂性是有限的，因此人们总是有意识地将问题分解、化简和转换。当我们把全部精力放在相对少的需求上时，可以更为深入地分析这些需求，有利于得到透彻的认识，从而设计出合理的架构。

Ÿ   第二，因为需求是“促成设计决策的因素”，因此需求的变更可能会引起架构设计不再适合。因此，我们希望能通过所有需求的一个子集来“驱动”我们的架构决策过程，这样可以减少需求变更对架构设计方案带来的冲击，使架构设计趋于稳定。如图13-1所示。

特别是，功能需求的数量是相当巨大的；通过选取不到20%的典型功能需求，进行有重点的深入分析来带动架构设计，可以节约很多时间。如果再考虑到需求变更的问题，在架构设计期间80%的功能需求的变更都不会对架构设计的推进造成冲击，这太有诱惑力了；毕竟，架构设计之时一般难以达到所有需求都稳定的状态。