寫在前面
ThoughtWorks每年都會出品兩期技術雷達，這是一份關於科技行業的技術趨勢報告，在四個象限：技術、平臺、工具以及語言和框架對每一個條目（Blip）做採用、試驗、評估、暫緩的建議。（參考閱讀：解讀技術雷達的正確姿勢）
一直以來，我們都未對每一個Blip做進一步的解讀，而這次決定嘗試一個新的專欄——《雷達嗶嗶嗶》，由作者根據自己實踐與理解，對雷達中部分條目作出解析，致力於用一篇篇短小精悍的文字，幫助讀者加深對雷達的理解。
今天是《雷達嗶嗶嗶》的第一篇，Blip是Lightweight Architecture Decision Records
位置：
2018年5月第18期技術雷達，技術象限，建議試驗
目標受衆：
系統架構師，技術管理者，開發設計人員
關注問題：
- 傳統的重文檔編寫維護量大，隨着業務發展，很難保持同步
- 在一些敏捷項目中，隨着關鍵文檔的缺失、項目Knowledge及決策丟失導致長生命週期的項目知識傳遞問題
解決方案：
使用“ Lightweight Architecture Decision Records”（輕量級架構決策記錄）來記錄項目的重要決策，並將其與代碼等其他項目資產一樣，納入到版本控制系統之中。
解讀：
“項目要不要寫文檔”一直是一個很有爭議的問題。在過去，項目一般都要寫衆多的文檔，類似於需求說明書、概要設計、詳細設計、數據庫設計和其他各種各樣的設計文檔，而這些文檔的作用往往只是爲了【過評審】或是【招投標】，寫文檔的形式也更多是簡單的複製粘貼。
項目拿下了，過審了，一旦開動起來，文檔反而就被束之高閣，再也無人過問了。
很多人沒日沒夜地寫着千篇一律的文檔、文檔、文檔……終於有一天，盼來了敏捷，並看到了敏捷宣言中碩大的一句：
（敏捷宣言）
唉呀媽呀，終於見到了親人，從此高舉着敏捷的大旗，與文檔勢不兩立。
再有人敢提起寫文檔，就把早已準備好的“敏捷大棒”從身後掏出來，劈頭就是一棒槌……
不得不說，敏捷又一次背了口黑鍋。敏捷宣言所推崇的並不是簡單的不寫文檔，而是認爲之前那種寫文檔的方式根本沒有體現出其應有的價值。還不如代碼寫的漂亮些，測試寫的完備些，讓代碼和測試成爲真正有價值的活文檔。
而這，相對於簡單的複製粘貼攢文檔，對於團隊的要求反而更高了。
世間萬物，物極必反。
隨着時間的推移，再好的敏捷團隊也會出現知識流失的問題，儘管有着完備的測試和易讀的代碼，但這些畢竟過於細節，無法快速還原當時設計或重構時的所有上下文。
所以技術雷達推薦使用“ Lightweight Architecture Decision Records”來記錄項目的重要決策，相比於傳統文檔，它最大的特點就是輕量（Lightweight），關注於創造價值而不是遵循流程。 讓我們看個ADR的模板：
（ADR Template）
同時技術雷達也建議我們不要將ADR束之高閣、放到Wiki或是文檔庫中。而是隨着代碼放到Git或其他版本控制工具裏，這樣既可以保持最大程度與代碼同步，又能跟蹤Decision的變更歷史。
推薦的Adr-Tools工具，可以幫助我們更容易的做到這些。
相關Blip及延展閱讀：
- Lightweight Architecture Decision Records
- Blog | Documenting Architecture Decisions | Relevance
- GitHub - joelparkerhenderson/architecturedecisionrecord: Architecture decision record (ADR) examples for software planning, IT leadership, and template documenation
- Documenting Architectural Decisions Within Our Repositories — Embedded Artistry
- Architectural Decision Records | adr.github.io
- What are lightweight Architecture Decision Records?
工具：
- GitHub - npryce/adr-tools: Command-line tools for working with Architecture Decision Records