架構決策記錄在 Spotify 的應用

雲栖号資訊：【 點選檢視更多行業資訊

】

在這裡您可以找到不同行業的第一手的上雲資訊，還在等什麼，快來！

Spotify 有多個團隊使用架構決策記錄（ADR）記錄他們做出的各項決策。ADR 為 Spotify 帶來了許多好處，包括改進新晉開發人員的入職管理，提升組織調整導緻項目所有權移交的靈活性，改善團隊之間關于最佳實踐認知的一緻性。

架構決策（AD）是一種軟體設計選擇，負責處理架構上很重要的功能性或非功能性需求。

由于其天生具備不斷演進的特性，是以架構決策記錄技術經常在靈活環境中使用。正如靈活專家 Michael Nygard 所描述的那樣：

靈活項目的架構必須以不同的方式進行描述和定義。并不是所有的決策都是一次做出的，也不是所有的決策都會在項目開始時完成。

架構決策記錄包括可以幫助我們了解特定決策及其結果的上下文資訊。此外，他們還可以記錄沒有做出的決策以及不這樣決策的原因。

Spotify 工程師 Josef Blake 表示，決定何時編寫 ADR 有時候并不容易，因為當一項決策對一個項目産生重大影響時，可能會存在多種了解方式。根據他的經驗，至少在下述三種情況下編寫 ADR。

首先，編寫 ADR 來記錄過去未記錄的決策。這可以確定每個人都清楚地知道存在這項決策。

同樣，如果做出了一項決策，而從來沒有記錄，那麼它能成為标準嗎？确定未記錄的決策，一種方法是在同行評審期間引入競争代碼模式或庫，進而引導審查者發現未記錄的決策。

對于會對系統産生很大影響（例如會破壞 API）的更改，編寫 ADR 是更改的最後一步。在這種情況下，Spotify 的工程師使用編寫請求評議（RFC）的方法，促使所有利益相關者就一個共用的方法達成一緻。一旦 RFC 過程完成，所商定的解決方案就會在 ADR 中記錄。

不過，Blake 評論說，ADR 不應該隻為具有重大影響的決策而編寫。

未記錄決策的代價很難衡量，但其影響通常包括重複工作（其他工程師試圖解決相同的問題）或競争性解決方案（兩個做同樣事情的第三方庫）。

在這種情況下編寫的 ADR 可以使情況變得不那麼複雜。

架構決策記錄決不是一種新技術。輕量級決策記錄在 ThoughtWorks 的技術雷達上已經存在了好幾年。如果你有興趣嘗試，可以在這個存儲庫中查找其他資訊和開箱即用的模闆。

【雲栖号線上課堂】每天都有産品技術專家分享！

課程位址：

https://yqh.aliyun.com/zhibo

立即加入社群，與專家面對面，及時了解課程最新動态！

【雲栖号線上課堂 社群】

https://c.tb.cn/F3.Z8gvnK

原文釋出時間：2020-05-13

本文作者：Sergio De Simone

本文來自：“

InfoQ

”，了解相關資訊可以關注“

”