《架构师修炼之道》摘录12-架构评估

本系列内容来自《架构师修炼之道》。在自己的笔记中以半摘录的方式，用 blockquote 穿插自己的思考和感悟，以加深对内容的理解和消化。

全书整体分为三个部分

1. 第一部分介绍软件架构的基础知识和架构师必备的设计思维
2. 第二部分讲解架构师需要掌握的核心技能和知识
3. 第三部分讨论一系列使用的架构设计方法

前两部分适合从头到尾通读，第三部分用于参考和检索。

对学生、家长、老师来说，成绩单是重要的反馈渠道。学生不必等到年底才知道自己的课程是“过来”还是“挂了”——通过每个季度的成绩单，就能判断自己是否获得了理想的成绩，以及哪些地方需要改进。架构评估的作用就像是成绩单一样，它让我们尽早发现问题，从而按计划交付系统。

架构评估可以提高开发效率，而不是单纯地占用编程时间。顺利的话，架构评估一小时就可以完成，它很容易融入现有开发流程中，而且不需要团队成员掌握什么新知识。

本章将学习对架构进行评估。评估结果可以用于指导团队、为设计决策提供支持、降低交付风险、提高架构设计水平。

12.1 评估得真知

架构评估让我们了解架构能在多大程度上实现目标。人们通常误以为在架构设计的最后阶段做一次槛车即可。这种想法是绝对错误的。如果架构设计有问题，那么所有工作都是徒劳，甚至连项目都无法实施。

你不必等到一切都完美了，才开始评估。没有哪个架构是完美的，也没有哪个架构是毫无可取之处。就像我们不能从单一视图看整体架构一样，我们也不可能一次完成整个架构的评估。

贯彻架构评估的一种方式是进行正式的签字验收。在组件必须满足严格标准的情况下，这样的签字显得尤为重要。例如，对于需要大量集成或对硬件有较高要求的系统，签字验收可以避免代价高昂的返工。

签字验收非常重要，但架构评估的作用远不止于此。如果只是把架构评估看成是开发流程中的阶段性检查，那真是大材小用了。架构评估是论证架构能否满足利益相关方需求的唯一方法。

架构评估要回答两个问题：架构有多好？好在哪里？为了回答这两个问题，我们需要用到关键架构需求（ASR）。架构越能满足ASR，就越符合目标要求。

12.2 检验设计

尽早检验，频繁检验。这条原则既适用于代码，也适用于架构。即使在架构设计初期，也有值得检验的地方。

架构评估需要做三方面的准备： 第一，要有评估对象，即架构的有形呈现；第二，要有评估准则，它反映利益相关方对优劣的看法；第三，制定计划，帮助评估者形成判断，指出架构的可取之处。

12.2.1 准备评估对象

有了评估对象才能开展评估。人们习惯评估有形的东西，而不是别人脑袋里的想法。首先要将架构展示出来，比如在白板上画草图，或者提供完整的架构描述。呈现架构的方式很多，例如：写代码：在纸上或白板上画模型草图：用绘图软件画模型：用 PPT 展示架构视图：展示实验结果；使用传统的架构描述、架构主旨、架构决策记录。

用直观的方式呈现架构，可以更好地展示设计思想和设计意图，让大家明白我们准备如何落实关键架构需求 (ASR），或者我们己经采用了哪些做法来落实。

想得到什么反馈，就应该准备相应的展示对象。例如：如果你希望评估某个质量属性，就应该展示包含该质量属性的架构视图。如果架构还不成熟，又希望做整体评估，那么可以画粗略的草图，表示设计还没有定型。而评估高风险、高成本的设计方案，最好采用正式的、精确的展示形式，以强调问题的严重性。

12.2.2 定义评估准则

架构的优劣有时不是那么明显。一个人眼里的杰作，在另一个人看来也许是糟粕。因此要建立评估准则，用各种指标判断架构的适用性。

架构准则包含两部分：指标是指待评估的架构属性；评分是对指标的打分。

在书中的Lionheart项目案例中，作者使用质量属性场景作为指标。评估者根据表格下方的评分标准打分。

根据关键架构需求选择指标

关键架构需求从利益相关方的角度定义了系统目标。第五章曾学习了列举关键架构需求，用于分析和评估。只要能准确、清晰地给出可度量的关键架构需求，就不难选择评估指标。合格的指标应该满足一下条件：

• 举足轻重、不可或缺。评估指标与关键架构需求有关，它体现了我们认为的好架构应该是什么样子。指标不应该包合锦上添花的东西，也不应该包含一些无关紧要的、对满足系统目标没有帮助的细节。
• 互不重叠。指标应该相互独立，每项指标都体现架构设计在某一方面的适用。理想情况下，每项指标都应该可以独立进行评估和打分。
• 易观察、可衡量。评估者必须能够对指标进行评估与打分。为了便于观察，应该采用恰当的形式将架构展示出来。评估过程应该收集数据，用于衡量指标。
• 准确不模糊。所有评估者都能够正确理解指标。

质量属性场景完全满足这些条件，可以作为评估指标。

选择评分标准

评估过程中，评估者用统一的评分标准为指标打分。评分标准包含评分等级。评分等级的多少由评估目标决定。下表列举了一些评分标准及使用场景。

undefined 上面的例子展示了评分标准的作用，但没有解释评估者是怎么打出分数的。用合适的方法引导评估者打分也很重要。

现在我们将架构展示出来了，也有了评分标准。最后一步是帮助评估者形成判断，进行评分。

12.2.3 形成判断

评估准则包含要回答的问题，如下图。如果我们能帮评估者形成判断，我们就能找到问题的答案。

形成判断的方法很多，如问卷调查、定向探索、风险手机、代码分析等。选择哪种方法要由回答问题所需的信息决定。下面的表格提供了一些参考示例。

架构评估的大部分时间都花在形成判断上。这种判断通常是在架构评估研讨会上通过协作产生的，因此我们有必要了解如何举办架构评估研讨会。

12.3 举办评估研讨会

架构评估研讨会的目标是收集与分析评估架构所需的数据。研讨会结束时我们应该能够确定架构能在多大程度上满足既定 质量属性和其他关键架构需求。

虽然评估研讨会的形式多样，但它们都遵循相同的流程：

1. 准备工作：设法将架构设计呈现出来；制定评估准则：选择收集数据的方法：邀请评估者。
2. 帮评估者做好淮各：向评估者展示架构设计，说明评估准则：阐述评估目标，回答评估者的问题。在开始评估之前，评估者应当充分理解架构设计、评估准则和评估的目标。
3. 评估：引导评估者通过一系列活动研究架构设计，形成判断，给指标打分。活动既可以合作开展，也可以是独立进行。
4. 分析与结论：收集评估者反馈的数据（评分）；汇总结果，给出结论。
5. 后续行动：根据研讨会的发现，决定下一步的行动。

下面逐一讲解以上步骤。

12.3.1 准备工作

首先要定义评估目标，然后围绕这一目标设法将架构设计展示出来。下表中列举了常见的评估目标和展示内容。

除此之外，还要制定评估准则，搜集评分所需的数据。另外，别忘了制定研讨会议程和准备相关资料。

选择评估者要兼顾利益相关方与非利益相关方。评估者应当关心系统，同时擅长发现细节问题。理想的人选应该精通行业知识和领域知识，或者对采用的技术、模式有专业见解。架构评估至少需要两位评估者。如有必要，最多可以邀请几十位评估者。

undefined 邀请完评估者后，我们要帮他们做好评估准备。

12.3.2 帮评估者做好准备

评估者应该掌握必要的信息，以便做出高质量的评估。这些信息包括：项目背景、关键架构需求、待评估的架构设计等。你要回答评估者就项目背景、评估准则、评估目标提出的问题。

准备好白板。如果时间允许，不妨在研讨会开始时当着大家的面把架构设计思路画出来，同时介绍项目背景。

帮评估者做好这些准备后，就可以开始正式评估了。

12.3.3 评估

在这个阶段，应该通过一系列活动引导评估者，帮助他们发现设计缺陷和潜在风险，从而形成判断。有许多方法可以帮助大家形成判断。这里我们先举几个例子，更详细的介绍请参考第 17章。

• 场景排查（见第17.8节）是最常用的方法，也是最基本、最可靠的架构评估方法。
• “问题-评论-关注事项”（见第 17.5 节〉是一种可视化的头脑风暴方法，可以帮助评估者迅速了解架构信息，发现疑点。
• 风险风暴（见第17.6节）也是一种可视化的头脑风暴方法，常用于发现系统特定视图中存在的风险。
• 绘制草图做比较(见第 17.9节）可以用来比较不同方案的优劣 （如比较提升同一质量属性的多种方案）。
• 代码评审（见第17.2节，不太容易发现架构的问题，但它可以识别代码与架构不一致的地方。代码评审也常常用来检查代码中的静态结构。
• 如果已经有了架构决策记录（见第 16.1节），那么可以借助它回顾设计决策并确定这些决策是否仍然有效。架构决策记录也可以用来评估适用性。

根据评估目标、评估时间，以及利益相关方对架构评估的熟练程度来选择评估方法。经验丰富的小团队（约三四个人）能够在 60 分钟内借助“问题-评论-关注-事项“方法做出有效的判浙。而缺少经验的团队可能要先花时间回顾质量属性场景和设计决策，才能取得较好的效果。

我们希望通过评估研讨会判断架构是否满足指标，但这不是研讨会的唯一目标。除了得出架构是否合格的结论，我们还希望了解如何改进架构设计。

12.3.4 分析与结论

无论评估使用什么指标，都需要得出清晰、明确的结论。架构评估的结论不应该是简单的”通过“和”没通过“。结论应该清晰表述架构满足指标的程度，同时提出改进架构的建议。除了判断架构是否满足要求，还应该分析架构为什么不满足要求，以及如何改进。

通过评估发现风险，找出架构设计可能引发的问题。把研讨会收集的数据共享给大家，请大家寻找规律。让大家就存在疑问的地方自由提问。通过开发性的提问环节找出大家对架构理解的差异。

得出结论后，还要决定接下来做什么。

12.3.5 后续行动

想解决评估过程中提出的所有风险和问题是不现实的，我们也没有足够的时问这么做。给问题排定优先级，把亟待解決的问题和值得研究但不紧急的问题区分开。可以指定一个人决定针对高优先级高的问题接下来应该做什么。

评估研讨会结束后，应该总结并记录发现的问题及后续行动计划，然后共享给所有人。小型研讨会可以群发邮件，写明后续行动要点：大型研讨会可以撰写一份简要的报告，并附上原始会议记录的链接。

总结报告向利益相关方展示了会议成果，可以作为架构设计进展的标志。总结报告对未来接手系统的架构师和其他人来说都有很高的借鉴价值。

黄金法则：架构劝和分析方法（ATAM）

架构权衡分析方法是迄今为止最系统、最全面的评估方法之一。在《ATAM： Method for Architecture Evaluation》和《软件架构实践》两本书对此有详细论述。本章介绍的评估研讨会就是在 ATAM 的基础上简化而来的。

ATAM 要求参与者具有较高的素质和丰富的经验，而且持续时间长达数日甚至数周。它适合用来设计导弹制导和自动驾驶这样复杂的系统。普通的软件系统采用本章介绍的方法就足够了。

12.4 尽早评估，反复评估，持续评估

开发团队最容易犯的错误足不开展架构评估，或者开展得台湾。越早评估，越容易发现问题并加以改进。把架构评估作为日常开发的常规环节效果会更好。

我们每天都有机会确认（或修正），设计决策。比如，给别人讲解架构如何提升质量属性时就是排查架构的绝佳机会；结对编程以及提交代码给同事审核时也是评估架构的好时机。

12.4.1 用评估金字塔平衡成本与价值

Mike Cohn 曾提出测试金字塔（test pyramid）的概念。他发现不同类型的测试适合发现不同的bug。有些测试容易创建和维护（主要是单元测试），但这类测试无法捕捉所有 bug，所以还需要补充一些复杂的、运行较慢的集成测试。

评估金字塔 (evaluation pyramid）有着相似的原理。大部分架构评估都能快速完成。对于快速评估无法发现的问题，可以补充少量深度评估。除了快速评估和深度评估，还可以采用定向评估（见下图）。

一般的系统大约需要开展一两次深度评估、几十次定向评估、几百次快速评估。深度评估可以视为系统生命周期的重大里程碑。定向评估可以定期开展，平均两到四周举行一次。快速评估则应该作为开发流程的一部分，每天开展一次（或多次）。

仅仅做到持续评估还不够，我们还需要熟悉常见的架构问题类型，确保评估覆盖所有范围。

12.4.2 发现各种类型的问题

分为七类问题，来看看每一类问题具体是什么。

风险 风险是未来可能发生的糟糕的事情。描述风险需要两个部分：条件和后果。条件是当前的实际情况，后果是由条件引发的、将来可能出现的不良状况。我们要么选择降低风险，要么接受它。

信息空白 有时，我们缺少足够的信息判断架构是否满足关键架构需求。询问系统如何运转以及如何满足特定的架构需求，有助于发现信息空白，进而采取措施。从未发现的信息空白称为盲点。盲点的存在对架构来说是巨大的威胁。信息空白需要做进一步的调查和研究。

麻烦 和风险不同，麻烦是已经出现的问题。你制定了设计决策，但事情并没有按你期待的那样发展，就有麻烦了。有时，因为情况发生了变化，上一刻的明智之举在下一刻变得不合适了，这也是麻烦产生的原因。如果麻烦已经存在于代码里，我们称之为技术债务。我们要么选择解决麻烦，要么接受它。

认知偏差 你说往左，团队却以为要往右，这就是认知偏差。如果有人对架构的理解与当前的设计决策不相符，就出现了认知偏差。认知偏差尤其容易出现在架构频繁演变的系统中。认知偏差可以通过沟通、指导解决。 架构变异 实现系统几乎不会按照我们预想的方式出现。理想中的架构与最终实现的架构之间的差异，称为架构变异，也叫架构偏移 (architectural drif）或架构腐烂（ architectural rot）。如果不保持警惕，架构每天都可能偏离既定设计，等到完成那天，你会发现它和原来的计划大相径庭。定期检查代码和文档，可以解决架构变异的问题。

情境偏移 世界无时无刻不在发生变化。开发过程中，新情况、新条件不断涌现。原来的快策有可能变得不合适了。也许我们刚做完设计决策，业务情境就发生了变化——这就是情境偏移 (contextual drif）。不定期地回顾业务目标、关键架构需求、利益相关方提供的材料可以避免情境偏移。

经验不足的架构师往往只对某一类问题敏感。如果你想改善架构评估的效果，有一个简单的方法，那就是多问一些之前没有问过的问题。试着提出不同类型问题，你才能知道自己有多么“无知”。

12.4.3 从仪式感弱的评估方法开始

方法的仪式感指的是运用它所包含的正式手续的数量。仪式感强的方法有很多约束，成本高，但其可复用性好，可以保证较好的效果。而仪式感弱的方法不拘小节，规矩少，易于上手，使用成本低，缺点是使用范围窄，难以保证效果。

如果团队刚开始做架构评估，采用 ATAM 这种仪式感强的方法可能导致大家产生畏难情绪。因此，刚开始时可以从仪式感弱的方法开始，你甚至没必要告诉团队我们正在做架构评估。

我举一个例子。做完白板涂鸦(见第 15.9节）后，把大家把留下一起做评估。你先起个头：“看起来我们的进展很不错。大家看看还有什么办法可以提升这个质量属性？”，把大家的发言记到白板上。跟大家一起总结新的发现，然后确定下一步的行动。这样不到十分钟时间，就能完成一次临时的架构评估。

仪式感弱的评估方法可以引发大家对架构的思考，同时树立质疑设计决策的团队文化。等团队适应后，可以逐步引入定向评估，最终进入深度评估。

我们必须承认强仪式感的确能让人感受到架构会议的专业性，但是一定程度上会增加参会人员的压力。最终的效果可能反而会不尽人意。对于没有类似经验的团队，可以尝试将会议流程简化，调动参会人员的积极性，把交流讨论的氛围活跃起来。类似头脑风暴会议，但又不完全是。前者用于讨论确定初步的架构方案的那个环节，然后在进入本章讨论的架构方案评估环节。

结束语

确定架构评估需要准备的资料，包括评估对象，评估准则。在组织评估会议前，需要提前准备，定义好评估目标，搜集评分所需要的数据，指定研讨会议程和其他相关资料。尽早评估，反复评估，持续评估。将架构评估加入到开发流程的一环中，有助于帮助完善架构。从仪式感弱的评估方式开始，减轻团队压力，引发团队对架构的思考，待团队适应之后，逐步引入仪式感强的评估方式，最终进入深度评估。

架构是团队文化的有机组成部分。糟糕的架构会让人痛苦不堪。架构评估能帮助我们理解如何改善架构设计。