再聊对架构决策记录的一些思考

这篇具有很好参考价值的文章主要介绍了再聊对架构决策记录的一些思考。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

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有着非常高的潜在价值,极度推荐大家在团队中进行实践。保持文档结构的简洁轻量和讨论的开放性,团队会非常乐于接受和参与这种高效的决策程和知识同步过。文章来源地址https://www.toymoban.com/news/detail-840785.html

到了这里,关于再聊对架构决策记录的一些思考的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 关于推荐场景的一些思考

    由于用户数的飙升,推荐使用的技术栈也在不断升级,以满足更高并发和更大数据量的推荐场景。 推荐相关的原始数据从小几十万到几百万,到几千万,再到上亿。 从全库的用户数据中load出满足条件的用户,在jvm做计算,得到推荐结果。 随着用户数量的上升,满足条件的用

    2023年04月09日
    浏览(46)
  • 我对ChatGPT的一些看法与思考

    1.1 ChatGPT是干啥的 ChatGPT全名Chat Generative Pre-trained Transformer,是美国OpenAI公司推出的一个聊天机器人程序,是人工智能技术驱动的自然语言处理工具,它能够通过理解和学习人类的语言来进行对话,还能根据聊天的上下文进行互动,真正像人类一样来聊天交流,甚至能完成撰写

    2023年04月16日
    浏览(40)
  • 解决前端恶意代码侵入的一些思考

    安全,特别是软件代码安全,近年来被业内人士频繁提出,可见其受重视程度。而这些,起源与全球化的开源大生产。 开源软件运动如火如荼的进行了二十四五年(如果从1998年2月3日在硅谷的一次会议中首次提出“open source”一说开始算 - 当时互联网先驱Netscape刚刚宣布开放

    2023年04月08日
    浏览(36)
  • 投资基金中一些别人的思考

    大部分投资者目前选择基金主要还是通过历史业绩判断未来。实际上影响基金未来业绩表现的维度比较多, 比如股票、债券等各类资产的持仓情况、仓位及换手率水平、基金规模等等。对于权益类基金而言,持仓行业分布怎样、 个股和行业集中度怎样?对于债券类基金而言

    2024年02月01日
    浏览(47)
  • AIGC批量图生成的一些思考

    从技术到先进生产力,从先进装备到作战能力,中间隔了一道GAP。现在AI技术进展很快,开源的模型大部分是单点或者一个模块单元的突破。如何把这些技术整装成作战单元,为业务带来实际的价值是我们必须要解决的一个问题。 这部分介绍的是如何搭建一个基于内容的图检

    2024年04月15日
    浏览(51)
  • 对区块链技术的一些新思考

    作者:朱金灿 来源:clever101的专栏 为什么大多数人学不会人工智能编程?   上周写了一篇《对区块链技术的一些思考》。之后和一些朋友进行了交流,纠正了我之前的一些关于区块链的错误认识。   在之前的文章中我质疑谁来提供运行区块链所需要的计算资源和存储资

    2024年02月17日
    浏览(34)
  • 三极管用作开关电路的一些思考

    为什么不管是NPN还是PNP,电路对应的负载要放到 集电极C ,而没有放到发射极E呢? 因为三极管的输入回路是从基级B控制发射极E,负载如果放到发射极E,那就会对输入回路造成影响。 比如说,Ube0.7V可以导通,但是由于负载接到了发射极E和GND之间,那么仍然想导通的话B点的

    2024年01月22日
    浏览(38)
  • 基础安全产品相关系统设计的一些思考

    目录 背景 风控业务架构 组件层 业务层 决策层 能力层 计算层 可视层 基础安全组件 落地难点 接入场景多 接入终端多 接入组件多 待解决问题 架构特性 安全性 稳定性 易用性 具体案例 问题分析 攻击场景 攻击还原 攻击步骤防御可行性分析 系统设计 系统架构 组件层 透传层

    2023年04月17日
    浏览(46)
  • ElasticSearch - 海量数据索引拆分的一些思考

    索引数据量亿+,查询请求耗时高,大量查询耗时超过 1s 的请求 数据的快速膨胀,带来了很大的资源消耗和稳定性问题, 比如如查询抖动等等 数据存在冗余,大量的冗余数据,带来了不必要的资源消耗 索引所在集群资源已接近瓶颈,但是扩容的话机器成本较高 一开始从索 引

    2024年02月11日
    浏览(40)
  • 风控安全产品系统设计的一些思考

    本篇文章会从系统架构设计的角度,分享在对 业务安全风控相关基础安全产品 进行 系统设计 时遇到的 问题难点 及其 解决方案 。 内容包括三部分:(1)风控业务架构;(2)基础安全产品的职责;(3)基础安全产品相关系统架构的设计要点。 文章会以总-分的形式进行阐

    2024年02月05日
    浏览(34)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包