ADR：将敏捷与架构紧密联系在一起的实践

做出良好的设计决策很困难，而改变它们则更难。架构决策为项目设定了方向，并指导代码中的较小决策，因此开发人员理解这些决策至关重要。文档可以提供帮助，但具体如何呢？

什么是ADR？ADR 是Arch Design Record 的缩写。

ADRs通常是一个小型文本文件，每个文件描述一个设计决策及其原理。ADRs的模板通常包括三个部分：背景、决策和后果。ADR的背景描述了直接影响设计决策的技术、业务、社会或政治环境。决策本身的简要描述概述了设计的选择方案。后果描述了决策应用后的预期结果。

例如，假设一支经验丰富的Java开发团队需要在紧张的时间表内交付一个Web服务。团队的经验、预期的项目时间表以及团队要交付基于Java的Web服务的技术限制都是上下文的因素。

针对这种背景，团队决定使用一种流行的框架作为架构的基础。由于这个决策，团队期望在短短几周内交付一个易于维护的解决方案，并将其他若干理想的质量属性融入Web服务的架构中。然而，采用这个框架会引入一个风险，即团队未来可能会遇到由于框架限制而无法解决的问题。

在这个例子中，原理主要关注质量属性（可维护性和上市时间）、工程风险和进度安排。后果描述了积极和消极的结果，但并不对假设的结果做出评判。尽管这个决策使团队能够快速交付并促进理想的质量属性，但同时也引入了新的风险，需要进行管理。接受这个决策意味着团队接受了所有这些后果。

讨论和记录设计决策并不是一个新的想法。在我们开发软件的整个过程中，团队一直在描述、讨论和分享他们的决策。新的是将决策视为团队记录的文档。回顾过去可以帮助我们理解为什么现在发生了这种转变，以及为什么敏捷团队愿意编写ADRs。

ADRs不是限制设计，而是直接赋予开发人员访问权限，并使他们有能力真在拥有设计及其历史。

尽管决策的重要性，但当软件架构在1990年代首次受到认真研究时，研究人员主要关注结构和抽象。佩里和沃尔夫（Perry and Wolf）是一个例外，他们在他们的公式“架构= {元素，形式，原理}”中突出包含了设计原理。大卫·加兰（David Garlan）和玛丽·肖（Mary Shaw）早期的著作中，更典型的架构处理方式间接地提及决策制定。决策被看作是为了得出关键架构抽象（如组件、连接器和模块）而做出的决策，但并非是其中的一个关键抽象。

回顾当时的情况，我们不应忘记软件架构在1990年代仍然是一个新兴的学科。经过几十年来使用临时模型处理日益复杂的软件系统，软件行业终于找到了一组初始的有用抽象，用于描述如何组织软件系统以促进理想的系统属性。当时的软件架构师通过视图、视图模型和架构风格获得了巨大的解释能力，这改变了游戏规则。

对于当时的非敏捷团队（《敏捷宣言》直到2001年才发表），这些强大的新思想是具有挑战性的。当时的设计实践耗时且需要深厚的专业知识才能应用得好。非敏捷派认为，必要的文档工作，尤其是使用早期1990年代常见的符号、工具和实践来记录架构的多个视图，耗时成本过高。因此，工作中重视的是可工作的软件，而不是全面的文档，这种单方面浪漫的种子就这样播下了。

随着工业界和研究界在新兴的软件架构学科上积累经验，越来越多的人认识到，成功实施系统架构需要的不仅仅是正确完整的架构描述。了解导致设计的决策路径的团队能够更好地扩展其组织、提高设计质量、应对员工流动并随时间推进系统的演进。因此，设计背后的原理理解具有实际意义。

鉴于在此期间确立了许多尖端技术，一些基础模块当时并没有被完全理解或欣赏，这似乎是合理的。自然而然地，这些被忽视的基础概念将在接下来的几年中进行研究。

在20世纪90年代末和21世纪初，设计决策在架构界越来越频繁地被讨论。软件工程研究所在其关于软件架构的一系列书籍中简要提到了这个主题，将其作为一种更丰富的模型描述方法和分析工具。研究人员和从业者，包括安东·詹森（Anton Jansen）、达纳·布雷德迈尔（Dana Bredemeyer）、扬·博什（Jan Bosch）、奥拉夫·齐默尔曼（Olaf Zimmerman）、巴里斯·阿夫杰里乌（Paris Avgeriou）、里奇·希利亚德（Rich Hilliard）、鲁思·马兰（Ruth Malan）、乌韦·范·海斯（Uwe Van Heesch）等人，分享了他们对设计决策的重要性和演变中的软件架构师在决策中的角色的观察。

在此期间，软件架构师对于设计决策的思考出现了明显的转折点。尽管可用的软件架构抽象强大而表达力强，但人们开始认识到，这些抽象对于设计和描述一个软件系统来说是必要但不足够的。从这个新的视角来看，设计决策与组件和模块一样是关键的架构抽象。

如果设计决策是一个新的抽象，它们与其他抽象有何关系，我们应该如何表达它们？许多软件架构界人士尝试通过创建以决策为重点的视图来纳入设计决策。

然而，敏捷团队对此并不感兴趣。将决策描述为视图需要他们完全接受他们已经拒绝的架构形式主义。杰夫·泰里（Jeff Tyree）和阿特·阿克曼（Art Akerman）注意到敏捷团队在融入架构理念时遇到的挑战，尝试通过使用结构化模板来编制设计决策目录，以求达到平衡。

尽管决策视图的适应性不佳，但架构界对设计决策的兴趣不断增长。2009年，菲利普·克鲁克滕（Philippe Kruchten）、拉斐尔·卡皮拉（Rafael Capilla）和胡安·杜埃尼亚斯（Juan Dueñas）将十多年的设计决策研究综合起来，呼吁软件架构界创建实用且有用的决策焦点视角。设计决策的时代正式来临，而敏捷开发很快也将显示出对软件架构的热情。

经过二十多年的时间，架构终于找到了一份让敏捷开发社区激动不已的礼物。这份礼物就是将决策打包成ADR（架构决策记录）。以决策为中心的设计与现有的架构抽象相辅相成，帮助团队描述了架构的一个新维度：随时间的变化。任何渴望接受变化的敏捷团队都会对这个想法感到兴奋。

在2010年代初，许多实践敏捷开发的团队受到克鲁克滕、卡皮拉和杜埃尼亚斯的呼吁，分享了他们在设计决策方面的经验。2011年底，迈克尔·奈加德（Michael Nygard）发表了一篇博文，描述了他团队使用模式的形式编写ADR的经验，采用了轻量级的模板。每个决策记录都被添加到一个不可变的决策日志中，随着时间的推移，构建了系统设计的历史。

ADR与架构界此前出现的其他方法有着明显的不同。任何团队成员都可以通过编写ADR来扮演架构师的角色。ADR不是为了意外地限制设计，而是赋予开发人员直接访问和拥有设计的权力。

ADR通过三种方式实现了这一点。

首先，编写ADR不需要特殊的工具。ADR以纯文本文件的形式存储，使用Markdown语言编写。任何人都可以通过文本编辑器创建ADR。图表可以使用任何工具创建，可以是正式的工具，也可以是非正式的工具，甚至可以是白板上的草图照片。将图表视为代码的工具在这个目的上尤其受欢迎。

第二，ADR存储在与这些决策相关的代码的版本控制库中。将ADR与代码存储在相近的位置，使开发人员更容易发现它们，并增加了开发人员阅读和遵循过去设计决策的可能性。由于ADR存储在版本控制系统中，它们也需要经过与代码相同的同行评审过程。这使得征求反馈和分享知识变得更加容易。

第三，ADR不需要特殊的符号或知识。ADR主要依赖于简明的散文描述。一个轻量级的模板为作者提供了结构和指导。开发人员在经过简短的培训后就可以编写他们的第一个ADR。具有深厚软件架构知识或经验的ADR作者仍然可以利用他们的知识编写简明而全面的ADR，但知识和经验并不是参与的先决条件。只要有写ADR的热情，任何人都只需尽力描述一个设计决策。

这些关于设计决策的新思路使得敏捷和软件架构之间火花四溅。即使只记录一次决策，也能带来很大的投资回报。每个ADR的成本是独立计算的，随着编写而测量。即使是架构快速演进的系统，投资也很容易被证明是合理的。根据这种经济原理，创建类似于决策视图的东西，比如描述架构演变历史的决策日志，几乎是免费的。

自从Nygard的博客发布以来的十年间，实践者和研究人员一直在探索设计决策和ADR。实际上，Nygard对ADR的看法并不是唯一的。Olaf Zimmerman描述的一个例子不仅强调过去的决策，还包括尚未做出的未来决策。由于Heiko Koziolek、Joe Runde、Lukas Wegmann、Nat Pryce、Oliver Kopp、Paulo Merson、Rafael Capilla、Thomas Goldschmidt等许多人的贡献，现在有了丰富的实用建议知识库，可以帮助团队有效地使用ADR。搜索一下今天的网络，你会发现关于设计决策、模板和描述设计原理的技巧有着充分的讨论。

敏捷和架构可能并非一见钟情，但从今天的合作情况来看，你无法想象它们曾经的矛盾。

设计决策并不是随着ADR的出现而发明的，但 ADR 使得设计决策以其他软件架构设计方法所无法做到的方式变得易于使用。这种广泛易用性使得实践敏捷的团队能够积极参与将设计决策从研究转化为实践。

ADR正在迅速成为软件行业的事实标准实践。随着实践软件开发团队的探索和完善，关于ADR的新建议、模板和变体不断涌现。当然，随着越来越多的团队通过编写ADR来改进其设计和文档实践，也会出现新的问题。知识管理日益成为软件开发团队必须应对的问题。

ADR并不完美。非结构化的散文通常难以分析。ADR强调了技术利益相关者，尤其是开发人员的观点，然而，非技术利益相关者可能并不太重视。这一现象应该会慢慢发生改变。毕竟，敏捷开发给软件开发与维护工作，留下的有用文档也太少了。

ADR虽然不需要特定的符号和工具，使得使用ADR变得容易，但对于初学者来说，ADR也会有一定的困难。因为对于软件开发工程师来说，可能写好文档要比好写代码难得多，何况是架构决策文档。

ADR最大的优势在于其低门槛。由于团队中的任何人都可以编写ADR，每个人都有机会扮演软件架构师的角色。任何人都可以编写ADR，这为逐步成长为软件架构师创造了机会。根据我的经验，ADR为越来越复杂的架构设计实践打开了大门。编写ADR的团队似乎在漫长的时间里不可避免地变得更好的软件架构师。即使这不是真爱，敏捷和架构似乎终于找到了一个共同的兴趣，建立更加稳固的关系。

乔梁老师开课啦~视频课程《持续部署训练营（Python版）》， 限时特价！

你的软件开发效率够高吗？质量够好吗？你的团队多长时间才能向用户实时推送一个生产变更？你的软件在发布时，你是否因担心软件交付质量而感到压力倍增？你是否遇到过部署失败，甚至导致停机的情况？持续部署可以帮助你消除软件交付的痛苦，让你能专注于为客户高价值的需求，而不会因为这些交付执行类问题而花太多精力。本课程通过学练结合，理论结合实战，让你体验如何使用构建-测试-部署管道，进行持续部署。并练习如何在有效监控部署的同时，逐步发布功能特性，并作数据库结构变化。

（扫码订阅）