架构决策记录在 Spotify 的应用

Spotify 有多个团队使用架构决策记录（ADR）记录他们做出的各项决策。ADR 为 Spotify 带来了许多好处，包括改进新晋开发人员的入职管理，提升组织调整导致项目所有权移交的灵活性，改善团队之间关于最佳实践认知的一致性。

架构决策（AD）是一种软件设计选择，负责处理架构上很重要的功能性或非功能性需求。

由于其天生具备不断演进的特性，所以架构决策记录技术经常在敏捷环境中使用。正如敏捷专家 Michael Nygard 所描述的那样：

敏捷项目的架构必须以不同的方式进行描述和定义。并不是所有的决策都是一次做出的，也不是所有的决策都会在项目开始时完成。

架构决策记录包括可以帮助我们理解特定决策及其结果的上下文信息。此外，他们还可以记录没有做出的决策以及不这样决策的原因。

Spotify 工程师 Josef Blake 表示，决定何时编写 ADR 有时候并不容易，因为当一项决策对一个项目产生重大影响时，可能会存在多种理解方式。根据他的经验，至少在下述三种情况下编写 ADR。

首先，编写 ADR 来记录过去未记录的决策。这可以确保每个人都清楚地知道存在这项决策。

同样，如果做出了一项决策，而从来没有记录，那么它能成为标准吗？确定未记录的决策，一种方法是在同行评审期间引入竞争代码模式或库，从而引导审查者发现未记录的决策。

对于会对系统产生很大影响（例如会破坏 API）的更改，编写 ADR 是更改的最后一步。在这种情况下，Spotify 的工程师使用编写请求评议（RFC）的方法，促使所有利益相关者就一个共用的方法达成一致。一旦 RFC 过程完成，所商定的解决方案就会在 ADR 中记录。

不过，Blake 评论说，ADR 不应该只为具有重大影响的决策而编写。

未记录决策的代价很难衡量，但其影响通常包括重复工作（其他工程师试图解决相同的问题）或竞争性解决方案（两个做同样事情的第三方库）。

在这种情况下编写的 ADR 可以使情况变得不那么复杂。

架构决策记录决不是一种新技术。轻量级决策记录在ThoughtWorks的技术雷达上已经存在了好几年。如果你有兴趣尝试，可以在这个存储库中查找其他信息和开箱即用的模板。

原文链接：

Architecture Decision Records At Spotify