1 引言
第一次在社区发文聊 ADR（架构决策记录）是在 2022 年 8 月份，在文章（轻量级 ADR 机制）中，具体介绍了以下几个主题：
•团队研发面临的次要问题
•ADR 的构造分析
•ADR 的存储模式
•ADR 在研发流程中所处的地位
•ADR 常见的误区与疑难
在实践中发现依然有一些普遍性问题与挑战能够探讨。
2 研发团队一些普遍现象
视角一：架构决策缺失是问题长期存在的广泛问题，但团队广泛短少治理
普遍存在的景象是团队对系统演进过程中的要害架构决策不足记录，尽管需要迭代过程中技术团队会产生系列的“技术计划”，依附这些“技术计划”追溯零碎的要害决策和演进仍然面临挑战：
•其一，“技术计划”个别会随着不同需要迭代散落在文档零碎中，不便于整合
•其二，技术计划是设计决策的“快照”信息，其体现的是决策的后果，并不能反映决策的演进过程和还原决策的上下文
•其三，技术计划个别是长文档，其“过期和不统一”的概率较大，少数状况下团队短少对历史技术计划的保护修改。
组织架构及业务调整，团队面临接手新的零碎，或者新的团队成员的退出，面对遗留 / 新的零碎，疾速相熟零碎是高效反对迭代建设的前提。但，大多数状况对遗留零碎的理解过程困难重重，很多时候依赖于可能曾经过期和散落的技术计划（技术视角），或者不得不梳理零碎代码以取得更多零碎常识。
对于技术而言，如果能有清晰明确的决策记录肯定水平上可能减速理解零碎的效率，升高认知老本。不论是从对现有零碎常识的积淀梳理，还是团队间技术决策的同步，亦或是在零碎交接场景下晋升信息传递效率，ADR 都是极具性价比且极易落地的实际。
视角二：对 ADR 的排挤
很多同学“排挤”ADR 的起因常见的是：
•其一：文档化 与技术人员的第一直觉相悖：“不太违心花太多的精力在文档撰写上”
•其二：排挤“评审”：认为 ADR 的评审是一种强流程的正式评审，大家不违心加入“评审会”，发起人也“不违心抛出本人的决策让大家在会上探讨”。这显然与 ADR 机制相悖，实质上，团队实际的该当是一种十分轻量级的、不应有太多累赘的架构决策机制，大家头脑风暴式的探讨、共识。
•其三：不确定什么场景下须要写 ADR，会感觉实际过程无准则可依
对于起因一和起因二的解决形式非常简单：放弃 ADR 模版的简略和轻量，突破对文档化的固有认知
对于起因三，其实少数状况下零碎负责人能够明确的 感知哪些决策对团队或零碎的影响“比拟大”，比方：
•新建子系统或零碎职责合并
•引入新的技术组件 / 框架或者中间件等基础设施
•工程构造的重大调整
•代码标准的变更
•其余
视角三：技术气氛不够凋谢，团队自组织水平较低
ADR 是一种架构决策，与参加零碎建设的每个人非亲非故，其要害价值不仅仅在于决策的留存和追溯，更为重要是在于通过干系人的探讨使得决策常识在团队间高效同步。大家对决策的制订独特参加、共识，越凋谢的气氛越有利于对决策充沛探讨，同时也有利于决策无效落地。
同时，麻利文化推广的轻文档机制与轻量级 ADR 并不抵触，ADR 与麻利文化相符合，在“自组织”团队中人造的适宜引入 ADR。
3 倡议
倡议一：先做起来，写一个 ADR 邀请团队成员一起探讨、决策共识
倡议二：ADR 放弃 足够轻量，在体现其价值的同时尽量减少团队累赘
倡议三：构建 凋谢 的技术气氛【重要】
探讨气氛肯定要放弃凋谢，切忌一言堂、强压式的决策，让团队成员都参加进来，抛出本人的观点或疑难，直到决策共识、通过
4 结语
不论是从治理视角还是技术视角，ADR 有着十分高的潜在价值，极度举荐大家在团队中进行实际。放弃文档构造的简洁轻量和探讨的开放性，团队会十分乐于承受和参加这种高效的决策程和常识同步过。