事实上，程序员讨厌架构师的未雨绸缪。而且同时，管理者也不喜欢这样。

有趣的事情是，在大多数情况下，在危机出现之前是没有人相信危险的，并且也是没有人愿意为此投入资源的。因此大多数架构师提出的“方案”都可能面临实施者的质疑：那个架构师的想法是多余的、没用的、空中楼阁。没人愿意为这些“可能的异常"付出代码、时间与防护性的子系统。

我至今所知道的唯一一件能让程序员——以及包括项目经理在内的整个团队—-所接受的预防性实施技术，大概就是“结构化异常”(try...catch...finally)。但仔细地探究也会发现，其实越是在项目中面临过工期拖延、系统崩溃以及未知的BUG的折磨的开发人员与团队，就越能接受在代码中出现更多的、貌似无用的异常捕获。所以看起来，真正的问题并不是程序员以及管理者不愿意推进“预防性的”架构，而是在于：一是他们无法感受到反复的系统危机所带来的痛苦折磨，二是他们无法找到有效的、可实施的方法来应对上述危机。

层次系统是极有可能符合这一要求的架构方法。但是就程序员与管理层所能接受的观念来讲，层次系统是过于复杂而随意的——只要会说“增加一层抽象”的，就都成了架构师。但正确的层次抽象是确实可以隔离复杂性的①,而且通过接口设计可以进一步减少、屏蔽或确指层间的依赖。但这些工作必然带来程序员的不满，因为接口的抽象与使用是多余的工作；也必然带来管理层的不满，因为“层次”这一系统抽象在事实上也约定了组织结构的规划。

测试驱动开发过程是另一个视角下的解决方法。从工程过程的角度上来讲，它通过明确系统的“问题”、"关键点"与“指标”等来将系统参数化，并将这样的参数作为过程中贯彻始终的标准加以推进。尤其重要的是，它事实上也内在地要求了系统构件间的“接口化"与“复杂性隔离”,因此它可以与层次系统有着相当良性的配合。

迄今为止，我没有看到过一个更好的、更简单的“架构”,能切实地应用于项目之中，将可能发生的危机阻隔在一定的范围之内。我在这里所说的“架构”是指两个方面，其一是架构师对系统的抽象方法，例如层次架构方法；其二是指由“软件架构”与“软件开发方法”配合所产生的整体效果，例如层次系统与驱动开发过程的配合。因而，我所指的“切实有效的架构”可以简单地描述为：目标系统、架构方法与开发过程协调统一的整体。yipindushu.com

①本书的第四篇会更加详细地说明这一事实，并探究层次系统隔离“可变性”的本质。

事实上，我认为只有这样(包括组织的、过程的、实施的等在内)的架构才是对“预防性”的整体求解。

然而，这带来了很高的组织成本。管理者喜欢简化问题，喜欢尽快投入行动，喜欢尽快看到结果——在这三个方面，管理者能很快与实施者达成一致，但与架构师则很难。追究这一问题，事实上症结在于架构与管理二者的相互脱责。首先，架构师所要做的事情，就是推进这些“看起来多余”的事情的实施。架构师若一力担之，便出现了架构师领导下的应急小组；架构师若置身事外，整个团队失去了在这件事情上的基本动力。所以，架构师必须在“方法”问题上迎合管理者，必须使架构的具体实施方法简化、可行、有效。

因此，真正有效的架构方法，就是让整个团队都把这些“看起来多余”的事情视为系统实施所必须的一部分，即“系统化方法”,亦即是团队可以应用的法子。若架构师的主意总是“我们需要一两个高手来做这件事”,或“我们需要一两个突击队”,那这并不会影响团队整体，对管理者来说也必是“可选的”。大多数情况下，管理者只会在不影响团队整体资源的配给时，才会同意这些想法。

而反过来，如果一个方法是“系统化方法”,它影响到团队整体的投入与产出，并且将深刻地影响到系统的推进，这时管理者才会真正地重视起来。这也才是考验管理者的团队决策能力的地方，即我们——整体地——要使用什么样的方法来工作。因为一旦管理者认为“这不可行”时，这个系统化方法便失去了价值。所谓不可行，本质上来说仍然是“对于当前的系统(团队、项目与产品目标)来说，是难于实施的”。

架构师必须与管理者在“系统化方法”上达成一致，从而在团队、方向、目标以及整体策略上，对系统施加约束。