軟件架構師至今仍被不少人視為軟件行業的“新興職業”，網上時不時有關于如何成為軟件架構師的文章，今天我們想分享的則是一位開發者在成為架構師后學到的重要東西。Tago Fabic 有十多年開發經驗，在 2019 年開始成為軟件架構師，他近日寫了一篇文章，總結自己在成為軟件架構師后的所獲所得和心路歷程，以下是他的分享。

在成為架構師之前，我從軟件開發工程師做到了技術負責人。但就我而言，架構師這個角色并不是一個管理角色：沒有一個人或一個團隊向我匯報，因此，我在技術主管一職中所發揮的一些關鍵能力在這里并不適用，不過其中有些部分可以適用（例如，指導等）。

這類角色的復雜性的確是因組織而異，于我而言，我認為應該首先確定什么是軟件架構師，以避免產生混淆。為此，我們主要依靠 The Software Architect Elevator（暫無中譯本，本文暫譯為《軟件架構師電梯》）一書作者 Gregor Hohpe 提出的概念。

（架構師是那些）在大型組織或復雜項目中將架構、技術細節、業務需求和人員聚集在一起的人。——Hohpe

Adevinta公司首席架構師 ?eljko Obrenovi?，和一位同事（我將他視為導師）在我們去年的一個峰會上提出了架構師是“超級膠水”的概念。

?eljko 在內部峰會上通過“電梯”的比喻對 Hohpe 的那句話做了精彩的闡述和分享，以讓大家能更深入地理解（我重繪了一小部分，但概念是相同的）。

確認了這個基本概念之后，下面我將繼續核心收獲的分享。

1 轉換思維——戰略先行、執行隨后

在擔任軟件架構師的幾個月中，我需要不斷提醒自己的一件事是，架構師的職責與我以前的角色（技術負責人）的目標有所不同。這兩個角色雖然有很多重合之處，側重點卻大相徑庭。

身為團隊中肩負交付任務的技術負責人，當時我的主要目標之一就是確保團隊盡可能有效地履行其承諾，完成任務。我可以把燃盡圖（用于表示剩余工作量的工作圖表）看做是衡量每個人工作效率的標準，然后自豪地寫下 Sprint 報告，介紹團隊兩周內的勝利、學習成果和趨勢。而當成為架構師之后，我需要“從戰壕后退幾步”，才能更宏觀地看到我們向前走的地平線究竟在哪。

成為一個團隊的技術負責人是我的“舒適區”——我知道如何去做、怎么進步，但是架構師需要轉換思維——積極分配時間進行咨詢（沿著各個“電梯”層），著眼于一年、兩年或三年之后的情況，并且清楚地把它闡述出來，以讓每個人都在同一個軌道上前行。

2 架構決策記錄用于討論而非批準

我們的團隊采用了架構決策記錄（Architectural Decision Record，ADR）的編寫方式，這確實是我近年來在我們組織中看到的很好的工作變革方式。

為什么這么說呢？讓我來描述一下采用架構決策記錄之前的情況：

面對被稱為微服務的新世界，開發團隊會硬著頭皮開始向左、向右和中心去旋轉服務（包括我在內）。

當團隊壯大時，應用程序就變成了一個服務森林。

好幾次，不同的團隊會推出新的服務，但是卻發現它已經重復了另一個服務的目的（或未來的目的），而這個服務是幾個月前創建的、并還在不斷發展和成熟。

同樣有幾次，工程師們（包括我自己）會在首次發布后就停下來，然后繼續下一個服務，而不去做其他必要的管理工作（例如學習如何監控和警報等等）。

步入架構決策記錄時代：為什么 ADR 受到我們工程師的青睞？因為它為工程師提供了一個工具，使他們能夠盡職地考慮決策的后果，并就組織中不同的專業領域進行有價值的對話。這使工程師們可以清楚地說明他們是怎樣做決定的，比如他們探索了什么，卻又為什么最終認為這并不是最佳的前進方式等等。

在我們采用 ADR 的初期，每一條記錄幾乎都是一件大事：有人將提出將 ADR 進行面對面的討論，由 20 多名工程師組成的小組就細節進行討論和辯論，我們發現自己在整個會議的一個小時里都在討論一條記錄。我們知道這種方法不會變得規模化，因此我們轉向 RFC 類型的、代碼審查式的審查，而且這樣做看起來更好。

像所有其它事情一樣，我們也在不斷地調整這一過程。由于架構決策的結果，我們不希望讓 ADR 成為實際交付的瓶頸，因此我們就拉取請求（Pull Requests）中 +1 的最低數量達成了共識。就是說，ADR 不尋求批準，而是針對不同課題做有效討論。

有一點提示：偶爾，ADR 編寫者可能會因為在決策過程中添加一些并不真正需要的信息而使記錄過長，那么可以設定一個預期，即 ADR 不是一個程序規范而是一份指南（也不是標準文檔）。

在我看來，沒有什么是天生不好的決定。只有不徹底、不夠充分的決定。

下面羅列一些有關 ADR 的優秀參考資料：

• 來自 Cognitect 的《記錄架構決策》（DOCUMENTING ARCHITECTURE DECISIONS）
• 來自 BetterProgramming 的《一款簡單而強大的工具來記錄你的架構決策》（A Simple but Powerful Tool to Record Your Architectural Decisions）——他們稱之為 LADR（LightweightADR，輕量級 ADR），但是我們使用的格式類似。
• 《軟件架構基礎》（Fundamentals of Software Architecture）一書也有一個關于架構決策記錄的好章節。

3 “這要視具體情況來看”

試想還是初級開發者的我要是穿越到現在，從現在的我尋求一些關于解決方案的意見，而現在的我會總說“這要視具體情況來看”，那年輕的我肯定對此會翻白眼，哈哈。

不過這是事實，但你接觸到的解決用戶問題的各種方案和方法越多，你就越了解一個組織的成功案例可能在某個環境中行得通，也可能行不通（就像我們現在聽到 “速贏” 或 “唾手可得的果實” 或流行語時產生的感覺一樣）。

在“這要視具體情況來看”的回答之后，確實有一些開放的問題，以便進一步豐富這項建議的背景和理由。你認為數據庫查詢的意圖是什么，或者緩存層是否有好處？需要的數據有多實時呢？認識到不存在銀彈（不管是在解決方案上，還是在運作方式上），總能使問題的解決變得更生動、富有創造力。

4 完美是不切實際的

代碼并不“關心”它的內聚或解耦程度；人們才會關心。——James Coplien
解決方案的完美之處在于接受或者承認，在某些時候，計劃 / 投資的改變并沒有給最終用戶帶來更多價值。

分解單體應用也是如此。我最喜歡的 Kelsey Hightower 的一條推文是這樣寫的：

很榮幸能在 @thenewstack 的 Context 播客上與 @el-bhs 辯論。雖然對單體和微服務存在爭議，但是最終，我們都認為這兩種架構模式都可以工作，而且對于復雜的組織而言，兩者的混合是不可避免的。

簡言之，優雅的解決方案始終是適合客戶 / 最終用戶需求的解決方案。

5 真相存在于代碼中，而非文檔中（或 JIRA Ticket 中，請注意這點！）

這一點，我想確實沒有什么可解釋的。我們知道文檔會過時，但是我們知道，一個合適且充分的文件還是有必要的。

我發現自己通常從文檔開始了解情況，然后在代碼中進行驗證，以確定它是否描述了一個準確的“故事”。如果不是，就在必要的時候更新文檔。

有很多策略或建議可供使用來保持文檔最新，但是最近我發現自己正在構建 Tiny 代碼（非常感謝 GitHub API），它從代碼本身提取信息來收集真相，或者依賴 Kiali 等工具的報告來實現流量與應用之間協作的可視化。

來自 Kiali 網站的屏幕截圖。能看到流量，這很不錯，并且它還提供了更多信息，比如每個箭頭的延遲等。

6 白板會議激發了歡樂（以及驚人的想法和觀點）

就連 Maria Kondo 也認為她所指的白板可以激發快樂。

大部分時間里，我發現自己變成了一只大黃鴨（Rubber Duck），工程師們可以在我這擴展或者驗證他們頭腦中的想法。（不是說我一直都是一個沒有生命的物體，如果我們對這個定義有點學究氣的話，哈哈）

我確實很懷念這場疫情爆發之前的一些事情，比如快速的白板會議，可以讓我和工程師們一起充實項目或者想法。我們先用 Slack 進行初步的討論，然后都跑到附近的白板上畫畫并討論解決方案。

開始居家工作之后，把這個方式變成在線對我來說非常重要——像 Miro、Mural、Excalidraw 這些工具，甚至是空白的谷歌幻燈片也行。

我的個人“大黃鴨”，給它取了個名字“Arthur”。

7 成為一名翻譯和溝通者所需的創造力

最后，我學到的另一件很酷的事情就是成為架構師，能夠將技術思想或概念進行翻譯，并將其傳遞給非技術受眾。

雖然我習慣于不斷向技術團隊分享計劃或解決方案，但要讓其他人也參與進來，我需要采取不同的方法。背景，背景，以及更多的背景，思考什么對你的聽眾很重要（例如，財務團隊不需要知道項目時間表的細目，所以你只需要給一個非常快速的涵蓋里程牌事件的幻燈片，但是要專注于明年的預算要花多少錢等等）。這些年來，我發現自己在演講方面變得更具有創造性：不僅僅是視覺上的，還有如何傳達每一次演講背后的故事。

“你所說的每一句話都會影響到某人，所以要注意你所說的每一句話，”這句話是我幾年前參加領導力培訓時獲知的，這話非常明智，但是我還想補充一點：要知道如何“翻譯”它。

PS：分享一些我曾經接觸過的書籍 / 參考，這些都是我作為軟件架構師的成長過程中接觸到的。

• Strengths Finder2.0：這本書（以及相應的調查問卷）是我在幾年前參加領導力培訓時推薦給我的。這本書很有見地——特別是當你仔細研究自己的長處時，你可以挖掘并確定那些被認為是弱點的地方，并利用它們改變你的工作和協作方式。強烈推薦！
• Accelerate: Building and Scaling High Performing Technology Organisations：隨著這份《DevOps 現狀報告》在某種程度上已經成為標準，這本書很好地提醒了我們現在所熟悉的概念的細節，4項關鍵指標等等。

其中最喜歡的一句話：“架構師應該關注工程師和成果，而非工具或技術。”

• Monolith toMicroservices：啊，這可能是我的圣經吧，已經有好一段時間了。顯然，這與我們一直在研究的實際架構有關，但是這本書提供了分解策略的良好指導——但是，在此之前，它會給你一些章節，詢問為什么你想開始這么做，然后給你一個概述，讓你知道計劃如何完成這個任務并不像開發Spring boot 應用程序那樣簡單。這本書與 Kelsey Hightower 的推文搭配簡直就是絕配。

其中最喜歡的一句話：“擁有微服務并不能讓你‘贏’。”

• Fundamentals of SoftwareArchitecture：這本書在導言和基礎章節之后，我確實沒有從頭到尾按順序閱讀，而是來回跳著閱讀關鍵章節，因為它講述了不同的架構風格。

其中最喜歡的章節：（眾多）架構師個性（哈哈）

• Team Topologies：在我的書庫中，這是一本相當新的書，它探討了思考團隊結構的方法，咳咳，康威法則（Conway’s Law），團隊類型不是用規定性的鏡頭，而是鼓勵團隊優先思考的探索性觀點。

其中最喜歡的話題：認知負荷。才華橫溢，思維轉變。

• Clean Architecture：又一部經典，不是嗎？雖然這是一種更為實際的書籍討論，但我還是不時地發現它是一個很好的參照點。

其中最喜歡的一句話（也是從某處引用的）：“如果你認為好的架構是昂貴的，那就試試壞的架構。”

• InfoQ 一直是個很好的參考渠道，這沒有什么好奇怪的。
• Dear Architects 周刊每周都有精彩的文章策劃——每周都有精彩的閱讀。

作者介紹：

Tago Fabic，主業是軟件開發者和技術負責人，副業是肖像攝影師。

原文鏈接：

https://tagofabic.medium.com/key-things-i-learned-after-moving-into-a-software-architect-role-dce88f9452a7
作者 | Tago Fabic
譯者 | 劉志勇
審校 | 燕珊
來源 | InfoQ
點擊進入獲得更多技術信息~~

總結

以上是生活随笔為你收集整理的9年当上架构师，我的很多想法变了的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。