Spotify有多個團隊使用架構決策記錄（ADR）記錄他們做出的各項決策。ADR爲Spotify帶來了許多好處，包括改進新晉開發人員的入職管理，提升組織調整導致項目所有權移交的靈活性，改善團隊之間關於最佳實踐認知的一致性。
架構決策（AD）是一種軟件設計選擇，負責處理架構上很重要的功能性或非功能性需求。
由於其天生具備不斷演進的特性，所以架構決策記錄技術經常在敏捷環境中使用。正如敏捷專家Michael Nygard所描述的那樣：
敏捷項目的架構必須以不同的方式進行描述和定義。並不是所有的決策都是一次做出的，也不是所有的決策都會在項目開始時完成。
架構決策記錄包括可以幫助我們理解特定決策及其結果的上下文信息。此外，他們還可以記錄沒有做出的決策以及不這樣決策的原因。
Spotify工程師Josef Blake表示，決定何時編寫ADR有時候並不容易，因爲當一項決策對一個項目產生重大影響時，可能會存在多種理解方式。根據他的經驗，至少在下述三種情況下編寫ADR。
首先，編寫ADR來記錄過去未記錄的決策。這可以確保每個人都清楚地知道存在這項決策。
同樣，如果做出了一項決策，而從來沒有記錄，那麼它能成爲標準嗎？確定未記錄的決策，一種方法是在同行評審期間引入競爭代碼模式或庫，從而引導審查者發現未記錄的決策。
對於會對系統產生很大影響（例如會破壞API）的更改，編寫ADR是更改的最後一步。在這種情況下，Spotify的工程師使用編寫請求評議（RFC）的方法，促使所有利益相關者就一個共用的方法達成一致。一旦RFC過程完成，所商定的解決方案就會在ADR中記錄。
不過，Blake評論說，ADR不應該只爲具有重大影響的決策而編寫。
未記錄決策的代價很難衡量，但其影響通常包括重複工作（其他工程師試圖解決相同的問題）或競爭性解決方案（兩個做同樣事情的第三方庫）。
在這種情況下編寫的ADR可以使情況變得不那麼複雜。
架構決策記錄決不是一種新技術。輕量級決策記錄在ThoughtWorks的技術雷達上已經存在了好幾年。如果你有興趣嘗試，可以在這個存儲庫中查找其他信息和開箱即用的模板。
原文鏈接：