摘要

• 在团队“完成的定义（DoD）”中添加可持续性标准，能帮助团队在发展最小可行架构（MVA）时评估架构决策的质量

• 最小可行产品（MVP）的进展可用于判断何时需做出架构决策，为 MVA 的决策提供具体指导，其中包括 MVA 何时可被暂时视为“已完成”

• MVP 这一概念从未消失，DoD 提供了一种可确保每个 MVP 及相关 MVA 都是可持续的方法

• 持续交付的实践为团队提供了一种自动化评估和执行“完成的定义”的方式。在快速的交付周期中，这是唯一可能确保稳健“完成的定义”的实用方法

• 软件架构如今已成为一个对决策不断重审的持续流程，DoD 中的架构标准时常变化。软件架构永远不会有“完成式”，但高效的自动化 DoD 却能在软件的每次发布时都对其进行改善。

• 完成的定义（DoD）* 是开发团队及利益相关者为确定软件产品是否可发布而制定的条件标准（关于完成的定义在敏捷场景中更为完整的描述，请见这篇博文）。DoD 可协助确保所有利益相关者对产品在发布前必须完成的最低增量标准达成共识。一般来说 DoD 会侧重于软件质量的功能方面，但团队若能将 DoD 扩展至架构层面的考量，便可增强产品的质量和可持续性。

架构与“完成的定义”

通常情况下，DoD 可能包括以下标准：

• 代码必须通过审查或检查

• 代码必须通过所有单元测试

• 代码必须通过所有功能性测试

• 产品必须没有缺陷

• 构建的产品必须在目标平台上部署测试

• 代码必须有文档记录

将 DoD 扩展至架构概念意味着通过评估解决方案的长期可持续性标准，对 DoD 进行增强，示例如下：

• 评估代码的可维护性与延展性

• 评估产品安全性

• 评估产品可扩展性

• 评估产品性能

• 评估产品可恢复性

• 评估产品开发过程中产生的技术债务（TD），并估算“还清”技术债务的时间

将 DoD 扩展至架构层面，让团队每次在评估产品是否可发布时，都能对其产品在一段时间内的可持续性进行估算。

软件架构、敏捷性，以及 DoD

在先前的系列文章中，我们介绍了最小可行架构（MVA）的概念，MVA 为最小可行产品提供了架构基础，很多人认为 MVP 是仅在产品开发的早期阶段有用的东西。

我们认为 MVP 和 MVA 是一系列渐进式交付，而非“一劳永逸”的。产品的发展是通过一个又一个 MVP，每个 MVP 理论上都应当能提升用户对产品的满意度，而每个 MVA 都应当能在支撑 MVP 交付的同时提升系统质量（见图一）。对使用敏捷方式的团队而言，每次产品的发布都是一次帮助团队评估本次发布价值的增量 MVP。

图一：MVA 的定义

MVP 暗含了对客户产品体验在其生命周期内保值的承诺。它不是个用于评估产品概念的“可有可无”的原型，MVP 一词中的“产品”意味着，认为该 MVP 有价值的客户有理由相信在未来他们将能继续使用该产品。

因为这种不言而喻的、对长期支持的承诺，每个 MVP 都有一个提供必要架构基础的 MVA，以确保 MVP 在长期内的可持续性支持。虽然传统 DoD 如 MVP 更侧重于功能性，但扩展至架构层面的 DoD 也可协助团队确保 MVA 也能“符合目的”，是“足够好”的。

正如 MVP 只能在将运行的代码交付到真实用户或客户，并根据他们的反馈进行评估一样，MVA 也只能通过对代码执行严格测试和审核进行评估。能验证架构假设的唯一方法便是构建架构并对系统的关键部分进行测试。不用测试全部系统，但需要覆盖足够的部分，才能对关键架构决策进行经验式评估。这就是 MVA 背后的概念。

在敏捷环境中，时间并不充裕

对使用敏捷中短周期工作方式的团队而言，如果不能将大部分评估工作自动化，那么他们几乎是没机会去评估架构的质量和可持续性的。对多数团队而言，光是开发一款稳定并可能有用的 MVP 就已经是项挑战了。通过构建 MVA 来确保 MVP 的可持续性则又是更多的工作量。

没有自动化，团队根本便找不到时间开发 MVP 或 MVA，并评估其是否能满足 DoD。添加人手也没用，这么做只会降低团队的效率。将评估工作交给其他团队也是不行，这么做也是会降低团队的效率，减缓接收重要反馈的速度。

实现 DoD 自动化最为有效的方式是将 DoD 构建到团队的自动化持续交付（CD）管道中，再加上长期运行的质量测试，一同协助评估 MVA 的适用性。这种方式有时被称作是使用适配性功能。这么一来的优势如下：

• 开发者能即时收获关于其工作质量的反馈

• 整体团队都会受益，不再需要围绕“尚未完成”的变更进行工作

• 系统中因为代码已经被交付到代码库而无法得到评估的部分可被经常性审查，以捕捉架构的退化

在实践中，这部分通常需要在持续交付的流程中添加以下的工具和评估步骤：

• 代码扫描工具。像是 lint 之类的工具已经存在了很长一段时间。虽然多数开发者都会用集成开发工具检测代码错误，但如果能有一种方式能够检测出常见代码错误、注释是否存在、是否使用代码格式约定，等等可被静态代码分析捕捉的一般情况，将很好地为自动化系统架构中基础评估搭建一个起始点。举例来说，有些类型的安全隐患也可被代码扫描工具检测到，模块化和代码复杂度的问题也能被标记出来。对代码扫描工具的反对声音则常称，如果没有对规则进行有效性地调整，那么这类工具带来的麻烦就要远超它们的便利性，开发者们也会无视它们，从而使其无效化。

• 构建工具。确保代码可通过认可的标准架构组件和环境设置构建为可执行文件，从而发现那些”在我的电脑上运行没毛病“的微妙问题。在开发者们使用不同版本的组件或未被团队其余成员认可的组件时，可能会引入难以发现的配置问题。有时候，老版本的组件会存在已知安全漏洞，补丁版本便能消除这类安全隐患。

• 自动化配置和部署工具。代码在构建为可执行文件后，便需要将其部署至标准的测试环境之中。配置标准类的决策是重要的架构决策，没了它们，代码将会以不可预测的形式运行失败。开发人员手动搭建的环境可能会与最终生产环境的配置相偏离，从而导致“在测试环境中运行没毛病”的问题出现。我们还发现在新的测试环境搭建不易时，比如需要手动搭建环境，人们会复用旧的环境。随着时间的推移，这也会导致测试环境的状态与预期的生产环境产生偏差。同理，如果人们需要手动部署代码，就存在遗漏东西或不按顺序的构建方式，从而导致测试环境与生产环境中微妙但却严重的不同。

• 单元测试工具。单元测试最基本应当确保 API 的运行符合团队的预期。自动化构建可以捕捉到接口的退化，单元测试则能确保其行为依旧是符合期望的。契约测试的方式 在应用程序破坏 API 契约时提供有效的评估方式。

将这些检测方法纳入持续交付流水线可为系统架构的适宜性提供即时的反馈，但这样一来这些检查速度也要加快，否则开发者们就要不干了。架构检查在持续交付流水线中仅仅是第一道防线，提供更为深层的检测应以后台自动化任务的形式运行，比如通宵运行或周期性后台运行，这类检查可包括：

• 基于 API 的功能性需求测试。敏捷开发周期时长短暂，不足以执行有意义的手动测试。因此，包括用户界面在内的一切都需要能通过 API 进行自动化测试。功能测试不算是架构的范畴，但给所有东西都配上 API 接口能让集成和系统的自动化测试以可扩展的形式进行。

• 基于 API 的可扩展性、吞吐量和性能测试。这些测试包括增加用户实例或进程实例数量，以观测系统在负载下的运行情况。即使是在后端主要由云基础设施动态复制的微服务组成，我们仍需要确保其可以轻松扩展用户的数量。

• 自动化可靠性测试。像是 Netflix 的“Chaos Monkey”这类方法，可以用于辅助评估系统是如何应对各类故障，从而协助团队开发更具弹性的架构。

其他有用的工具或手动技术包括：

• 测试数据管理。测试数据的创建、维护、随机化和刷新是复杂且易出错的。因为这部分很难，所以人们往往不愿意去做，他们会复制生产的数据，从而导致安全隐患出现，或者他们会使用手动创建、无法反馈现实世界中边缘案例或数据量的小批量数据。这样做的结果就是重要的行为缺陷、未处理的越界条件、堆栈溢出、竞赛条件和安全错误等严重质量问题一直无法被发现。

• 代码和架构审查。人工进行的代码质量检查以及架构的完整性、可靠性和可维护性或许很有价值，但如果企业希望能在较短的周期内交付产品，那么这些往往不会阻碍产品的发布。这些被发现的问题现实存在且需要被处理，但如果组织希望能快速收获客户反馈，人工审查就必须要将关注点放在重要但不会影响交付的质量问题上。人工检查根本无法应对变化的速度和数量。

• 白客和模拟攻击。我们所处的世界中，漏洞不断被测试。已知的漏洞测试作为代码扫描中基础问题的延伸需要被自动化，但经验丰富且具有创造力的友方黑客仍可通过不断尝试渗透系统，发挥出重要的作用。白客发现的漏洞也应被纳入前文中所述的自动化测试范畴之内。

“完成的定义”是否能被覆盖？

严格来说，答案是否定的。如果团队认同 DoD 标准可以真实反映发布产品的所能接受的最低增量（MVP）界限，那么团队就不应以任何理由降低这一标准。没人会强迫他们采用别的 DoD，这是团队自己的决定，但这也意味着他们不应该因为其不便利而将之抛弃。

也就是说，一个团队应当对可发布的内容对自身以及客户意味着什么有过深思熟虑的探讨。团队的 DoD 可能是固定的，但他们或许也会希望能有独立运行的测试类别，能为他们的发布决策和架构决策提供更多信息。如果团队愿意通过发布 MVP 以获得客户反馈，那么尤其是在产品生命周期早期，他们也会愿意牺牲产品的可扩展性或可维护性，团队会有意识地承担起技术债务。但在做出这一决定之时，团队也需要明白，如果他们做出的决策导致产品无以持续，那么他们可能会在无意中扼杀产品。

架构是否有完成之时？

随着每次 MVP 的交付，其可能结果大概有以下几类：

1. MVP 成功，并且团队认为 MVA 无需变动

2. MVP 成功，但 MVA 缺乏可持续性。这种结果可能会在上一种情况后的一段时间内出现，即使 MVP 没有变化，MVA 也会随时间退化

3. MVP 多半成功，其功能性符合多数商业利益相关者的需求，但 MVA 的质量属性需求（QAR）没能完全满足。MVA 需要改善，技术债务也会由此而生。

4. MVP 部分不完全成功，但可被修复。因此，MVA 也需要变动，技术债务同理也会累积

5. MVP 不成功，因此 MVA 并不重要

我们可以将这五种可能情况分为四类，通过下面这些问题判断我们是否真的“完成”了：

• 情况一（结果一）：在这种情况下，我们或许已经“完成”了，毕竟 MVA 和 MVP 似乎都是成功的。然而，真的如此吗？MVA 的可持续性怎么说？MVA 真的不会随时间增长而改变？技术负债（TD）也不会随着这些的改变而累计吗？

• 情况二（结果二）：这种情况下，MVP 可以视作完成，但 MVA 的长期可持续性仍然存疑。我们要如何确认这些疑问并证明 MVA 的不可持续性？在交付 MVP 时是否产生了过多的技术债务？是否测试了关键的 QAR，如可扩展性、性能和弹性这些是否能在合理时间内得到满足？是否能估算出“偿还”迄今为止产生的部分技术债务所需要的工作？

• 情况三（结果三与四）：在这种情况下，MVP 多半成功，但 MVA 因为仍需要重大架构变动而无法持续，需要立即或在近期做出重大架构改动。换句话说，我们的架构尚未“完成”。那么我们要如何评估 MVA 的可持续性？是否需要测试系统的可扩展性和弹性？随着时间的推移，架构的性能会如何变化？MVP 的交付过程中产生了多少技术债务？

• 情况四（结果五）：这是唯一一种可以认为“已完成”的情况，但明显这是反话。这意味着我们又要回到画白板的境况了，通常是因为组织对客户的需求和理解的严重不足。

总之，DoD 的架构标准从本质而言便是短期存在的。只要还在采用 MVP，MVA 就永远不会真正“完成”。正如我们在上一篇文章中指出，团队必须要抵抗 MVA 所带来的两种诱惑：一是完全忽视 MVA 的长期价值，只关注通过“一次性” MVA 快速交付产品功能；二是将架构搭建过了头，去解决团队永远不会遇到的问题。后者对传统团队而言颇具诱惑，因为他们总是以为自己的时间很充裕，而前者则通常会存在于敏捷团队中，因为他们似乎永远没有足够的时间完成需要的工作。

总   结

“完成的定义”有助于敏捷团队做出发布决策并对他们的工作提供引导。多数 DoD 的关注点在于功能性的完备性，但因此也可能会导致发布的产品会随着时间推移而难以持续。将架构层面纳入 DoD 的考量范畴可帮助团队纠正这一问题。

对绝大多数团队而言，他们连功能性 DoD 的评估就就已经快没时间去做了，更别提架构方面的考量。现实中的团队不可能为这项工作特意腾出时间，并冒险让利益相关者产生不满。唯一实际的解决方案就是将架构问题在内的尽可能多的 DoD 自动化，才能在架构问题出现时有空闲去应对。

随着 DoD 范围扩大到架构层面，最小可行架构（MVA）的概念也能帮助他们限制架构相关工作到可支持最新版本发布的绝对必要范畴，这可被看作是团队最小可行产品（MVP）的发展演进。

通过高自动化的 DoD 评估 MVA（以及发布版本的功能性方面），可以为团队提供坚实的经验证据，证明他们的架构与目标相符，这是纯人工的检查永远无法做到的。人工检查仍然有用，但会更多地用在开发解决问题的新思路和新方法上面。

现代软件架构已经发展为了一个不断重审决策的持续流程，将“完成的定义”扩展到架构层面关注点，有助于团队不断检查并验证或拒绝他们的架构决策，避免不健康的架构技术债务的累积。

原文链接：

Enhancing Your “Definition of Done” Can Improve Your Minimum Viable Architecture(https://www.infoq.com/articles/definition-of-done-mva/)