亚马逊云科技发布了使用架构决策记录（architecture decision record，ADR）的指南。他们推荐了一个在软件工程团队中采用和审查 ADR 的过程，这个过程的结果是包含已批准、已拒绝和已废弃的 ADR 集合的决策记录。
亚马逊云科技提出该 ADR 过程的目的是改善架构决策，避免对相同主题的重复性讨论，并有效地对决策进行沟通。
ADR 是一个简短的文档，描述了会影响软件架构的团队决策。它不仅包含决策，还包含了相关的背景和影响。一组 ADR 组成了一个决策日志，它提供了关于项目或产品的更广泛的背景、设计信息和实现细节。
ADR 过程中，最常见的输入是需要在架构方面进行重大决策的功能性或非功能性需求。发现了这种决策的任何团队成员都应该创建一个 ADR。使用模板可以简化 ADR 的创建，并且能够确保它会捕获所有相关的信息。
按照亚马逊云科技的指南，创建 ADR 的团队成员也是该 ADR 的所有者，要负责维护和交流它的内容。在初始阶段，ADR 所有者会提供一个“proposed”状态的 ADR，这意味着它可以进行审查了。随后，ADR 所有者要安排一个团队会议，以审查并决定该 ADR 要被批准、返工还是拒绝。
如果团队发现该 ADR 需要改进的话，它会依然保持“proposed”状态，所有者和其他团队成员会对其进行优化。否则的话，ADR 的状态将会变为“accepted”或“rejected”，ADR 就不可改变了。如果团队需要更新这个决策的话，那应该提出一个新的 ADR，当该 ADR 被批准后，会取代之前的 ADR。
下图展示了 ADR 的创建、所有权和采用的过程。
/filters:no_upscale()/news/2022/06/aws-adr-guide/en/resources/1adr-creation-1654293535205.png)
亚马逊云科技建议，ADR 应该有一个变更历史。一旦 ADR 被批准或拒绝，它就应该被认为是不可改变的。如果团队批准了一个新的 ADR，并且该 ADR 取代或更新了以前的决策，ADR 的所有者应该将旧 ADR 的状态变更为“superseded”。如果新的 ADR 被拒绝了，则不需要对旧的 ADR 进行任何改变。
下图显示了 ADR 的更新过程。
/filters:no_upscale()/news/2022/06/aws-adr-guide/en/resources/1adr-inspection-1654293535205.png)
决策日志会随着时间的推移而增长，它会提供团队所做出的所有决策的历史。例如，在代码或架构审查期间，团队可以使用决策日志作为参考，以验证变更是否符合商定的决策，或者是否需要创建一个新的 ADR。
原文链接：
中国开发者画像洞察研究报告 2024
分析开发者的行为模式、工作价值、职业发展等内容，帮助整个行业生态更深入地理解开发者，为他们提供更精准...
评论