架构决策记录-ADR

发表于 更新于 阅读次数： 本文字数： 730 阅读时长 ≈ 1 分钟

之前年终Review时，与同事探讨一个项目总是会面临各种情况，而项目底层的架构，也是一直在发展，架构背后的人也是在发展，面对这种发展，我们需要系统反思、调整、分享。只有这样才能校正，才能统一整个team的认知等。

在交流中同事推荐我去了解 Architecture Decision Records (ADRs)，这个概念之前只是喵了一眼，毫无印象，答应要学也一直没有去学=》惭愧。于是今天还债。

ADR

ADR全称Architecture Decision Records,汉化后就是架构决策记录，之所以有这样一个概念，其背景正如上述我所提到的，项目是一个变量，在发展，而在这变化中，我们需要去系统记录梳理这些变化点。对于所有的成员也需要一种形式可以了解这些，而最合适的就是文档化。

当前我们是如何做的

  1. 博客，我喜欢博客去总结一些变化
  2. 公司文档-Confluence
  3. 个人脑中

如上，其实缺乏一个系统的理论和方式，so，ADR确实可以补充项目运作上的 一点短板。

ADR模版

业界的前辈们已经总结了一个，当然这只是个实践的一种，具体我们可以活学活用。这个没有标准答案，有收益即可。

写在最后

  1. cl means changelist，当前项目代码往往是在版本管理系统中，CL可以完全体现我们整个项目的代码层面变化。ADR决策最终一定体现在代码上，但决策与代码并非一对一，并且决策也有不提倡，废弃一说，所以如果单纯ADR放在CL上去做并不合适
  2. 架构最终仍然影响的是代码，是项目，所以MD文档化，跟着项目强相关托管挺合适
  3. ADR只是个系统化面对软件工程中一个问题的理论，so，活学活用。