Spotify的几个团队使用体系结构决策记录(ADR)来捕获他们做出的决策。 发展成果评估为Spotify带来了一些好处，包括改进了新开发人员的入职，提高了由于组织变化而移交项目所有权时的灵活性，以及改进了团队之间关于最佳实践的一致性。
架构决策(AD)是一种软件设计选择，它解决了在架构上具有重要意义的功能或非功能需求。
架构决策记录是一种技术，由于其不断变化的性质，经常在敏捷上下文中使用。 就像敏捷专家Michael Nygard写的
敏捷项目的体系结构必须有不同的描述和定义。 并不是所有的决定都将立即作出，也不是所有的决定都将在项目开始时作出。
体系结构决策记录包括了解导致给定决策的上下文及其后果的信息。 此外，它们还可以记录未作出的决定和原因。
Spotify工程师Josef Blake说，决定何时应该写ADR并不总是容易的，因为当一个决定对一个项目产生重大影响时，有多种理解方式。 根据他的经验，至少有三种情况下，写ADR应该是一种无需考虑的方法。
首先，您将希望编写一个ADR来捕获过去没有记录的决定。 这将确保每个人都清楚决定的存在。
同样，如果一个决定是作出的，但从来没有记录过，它能成为标准吗？ 识别无文件决定的一种方法是在同行评审期间。 引入相互竞争的代码模式或库可以引导审阅者发现无文档的决策。
通常，编写ADR是进行更改过程中的最后一步，该更改将对系统产生很大影响，例如更改将破坏API。 在这种情况下，Spotify工程师使用写评论请求(RFC)作为一种手段，以促进所有利益相关者就共同的方法达成一致。 一旦RFC过程完成，商定的解决方案将在ADR中捕获。
布雷克说，发展成果评估不应该只针对影响很大的决策。
无证决策的成本很难衡量，但其影响通常包括重复的努力（其他工程师试图解决相同的问题)或相互竞争的解决方案(两个做同样事情的第三方库）..
在这种情况下，编写ADR还有一个额外的好处，即不特别复杂。
建筑决策记录绝不是一种新颖的技术。 特别是，轻量级决策记录在ThoughtWorks技术雷达上已经有几年了。 如果您有兴趣尝试一下，您可以在这个存储库中找到额外的信息以及现成的模板。