“我怎么才能成為一個軟件架構(gòu)師？”

這是很多小伙伴問我的一個問題，最近看到Kai Niklas講架構(gòu)師的一篇文章，其中的真知灼見引起了我的強烈共鳴，尤其是后面的非技術(shù)部分。翻譯過來（略有刪減），分享給大家。

我事先給一位同學(xué)看了一下，他說：當(dāng)個架構(gòu)師太難了吧，又要精通技術(shù)，還得會溝通，平衡，營銷..... 我還是爭取做個技術(shù)專家吧！

捫心自問，我這個架構(gòu)師在很多方面也做得遠遠不夠，繼續(xù)學(xué)習(xí)吧！如果你的未來職業(yè)目標(biāo)是架構(gòu)師，強烈建議仔細閱讀并收藏。

01什么是軟件架構(gòu)師

在我們一頭扎入細節(jié)之前，我們先得知道軟件架構(gòu)和架構(gòu)師到底是什么：

軟件架構(gòu)師是一個軟件專家，他可以做出高層的設(shè)計決定，規(guī)定技術(shù)標(biāo)準(zhǔn)，包括編碼標(biāo)準(zhǔn)，工具和平臺 -- Wikipedia

軟件架構(gòu)是一個系統(tǒng)最基本的組織方式，由其組件，組件之間的關(guān)系，組件和環(huán)境的關(guān)系表達出來。也包括決定設(shè)計和系統(tǒng)演化的原則。--Handbook of Software Architecture

02架構(gòu)的級別

架構(gòu)可以在不同的抽象級別上完成， 不同的級別要求不同技能，有很多分類標(biāo)準(zhǔn)，我最喜歡的是這三個級別：

Application Level （應(yīng)用級別）：架構(gòu)的最低級別，專注于單個應(yīng)用，有非常具體的設(shè)計，溝通通常局限在開發(fā)團隊

Solution Level （解決方案級別）：架構(gòu)的中間層，需要關(guān)注幾個應(yīng)用來實現(xiàn)一個商業(yè)的需求，有部分高層的設(shè)計，但大多數(shù)還是具體的設(shè)計，溝通需要跨越多個開發(fā)團隊。

Enterprise Level (企業(yè)級別)：架構(gòu)的最高級， 關(guān)注多個解決方案，這一層的設(shè)計比較抽象，需要解決方案架構(gòu)師和應(yīng)用架構(gòu)師去細化。溝通跨越整個企業(yè)組織。

有時候，架構(gòu)師被看作不同利益相關(guān)者之間的粘合劑，比如：

水平方向：在業(yè)務(wù)人員和開發(fā)人員建立溝通的橋梁

垂直方向：在開發(fā)人員和經(jīng)理之間建立溝通橋梁

技術(shù)領(lǐng)域：集成不同的技術(shù)和應(yīng)用。

03軟件架構(gòu)師的日?；顒?br>

為了理解軟件架構(gòu)師需要哪些技能，我們得先來看看架構(gòu)師的日?；顒?/p>

• 確定開發(fā)的平臺和技術(shù)

  
  

• 確定開發(fā)標(biāo)準(zhǔn)和規(guī)范：編碼標(biāo)準(zhǔn)，工具，評審流程，測試方法等

  
  

• 根據(jù)需求，設(shè)計系統(tǒng)并且做出架構(gòu)設(shè)計決定

• 把架構(gòu)設(shè)計和決定文檔化，和團隊溝通

  
  

• 把高層的設(shè)計變成底層設(shè)計

  
  

• 檢查、評審架構(gòu)設(shè)計和代碼，比如看看確定的模式和代碼標(biāo)準(zhǔn)是否正確施行

  
  

• 和其他架構(gòu)師、利益相關(guān)者協(xié)作

• 指導(dǎo)開發(fā)人員

注:?架構(gòu)設(shè)計是一個持續(xù)的活動，所以這些活動會一遍一遍地完成。

軟件架構(gòu)師所需的重要技能

根據(jù)我的經(jīng)驗，閱讀的書籍，以及參與的討論，我可以列出這10個技能，每個架構(gòu)師都必須具備：

設(shè)計, 決策，簡化, 編碼, 文檔, 溝通, 估算, 平衡, 咨詢, 營銷

我們一個個來說，對每個技能我都會列出一些我的見解，你應(yīng)該采取的行動，以便在這個技能領(lǐng)域持續(xù)提高。

04設(shè)計

是什么造就了好的設(shè)計？這可能是最重要，并且最具挑戰(zhàn)性的問題，讓我們先從理論開始。

理解基本的設(shè)計模式：為了開發(fā)一個可維護的系統(tǒng)，模式絕對是架構(gòu)師最重要的工具之一，使用模式，你可以復(fù)用設(shè)計來決定那些通用的問題?！八娜藥汀钡摹对O(shè)計模式：可復(fù)用的面向?qū)ο筌浖A(chǔ)》是每個開發(fā)人員的必讀書籍。盡管過去20多年了，模式依然是軟件架構(gòu)的基本單元。

比如書中描述的MVC模式被應(yīng)用在很多領(lǐng)域，也是很多新模式如MVVM的基礎(chǔ)。

深入挖掘模式和反模式：理解了基本的“四人幫”模式以后，你需要把你知識擴展到更多的軟件設(shè)計模式中，或者根據(jù)自己的興趣，深入研究，例如Java并發(fā)模式。

在應(yīng)用程序的集成領(lǐng)域， 我最喜歡的是《企業(yè)集成模式》，這本書適用于各種領(lǐng)域，只要兩個應(yīng)用需要交換數(shù)據(jù)，不管是很古老的基于文件的交換還是現(xiàn)代的微服務(wù)架構(gòu)，都可以參考本書。

了解軟件質(zhì)量的度量方式：我們希望我們的系統(tǒng)是可以維護的、可靠的、安全的、可以測試的、可以擴展的、可用的...... 為了達成這些目標(biāo)，必須要把系統(tǒng)架構(gòu)設(shè)計好。你可以參考這個：

理論很重要，實踐更加重要，否則你就會變成一個象牙塔架構(gòu)師。

不斷嘗試和理解不同的技術(shù)棧 ：我認為這是成為架構(gòu)師非常重要的事情， 你很難從抽象的PPT中學(xué)到真東西，你得嘗試不同的、新的技術(shù)棧，親自感受一下它帶來的好處和引發(fā)的“疼痛”。另外也可以嘗試不屬于你所在領(lǐng)域的技術(shù)，例如你對SAP R/3 非常擅長，那你應(yīng)該也試試JavaScript。

分析、理解那些應(yīng)用良好的模式：看看你當(dāng)前使用的框架，例如Angular， 你可以研究很多以及付諸實踐的模式，如觀察者?？纯此窃趺丛诳蚣苤惺褂玫模瑸槭裁匆@么使用。如果你愿意投入更多的精力，那就深入源代碼看看它是如何實現(xiàn)的。

保持好奇心，參加一些公司之外的社團活動：比如Java User Group會討論很多主題，從最底層的編碼到高層的架構(gòu)，我很喜歡這樣的活動，因為它會讓我跳出工作來思考，并且加強個人社交網(wǎng)絡(luò)。

05決策

架構(gòu)師需要能夠做出架構(gòu)決定，引導(dǎo)項目和組織走在正確的方向。

確定優(yōu)先級：有些決策非常關(guān)鍵，如果沒有在早期確定下來，就會出現(xiàn)一些變通的臨時措施，導(dǎo)致后續(xù)難以移除，變成維護的噩夢。更差的情況是，程序員需要停止工作，等你做出決策。

為了避免這種情況，必須要把這些決策按優(yōu)先級排序，我建議看一看敏捷軟件開發(fā)中非常流行的Weighted Shortest Job First (WSJF)?模型。

了解你的能力：不要在你的能力之外做決定，這非常關(guān)鍵，如果你不遵循的話可能會毀掉你架構(gòu)師的崗位。

所以一定要和你的同伴明確你承擔(dān)的職責(zé)和你的角色。作為低級別的架構(gòu)師，你可以提出對高層架構(gòu)的建議，但是不要擅自做主。我建議要經(jīng)常和同伴審視那些關(guān)鍵的架構(gòu)決定。

評估多個選項：涉及到?jīng)Q策時，要列出多個選項。在我參與的大多數(shù)決策中，都有不止一個可能（好的）選擇。僅僅提供一個選項說明你沒有完成自己的工作，沒法完成決策。各種選項要通過可以度量的事實（如許可證費用，成熟度）而不是個人感情來比較，這樣才能真正完成決策。

06簡潔

要謹記解決問題的奧卡姆剃刀原則：如無必要，勿增實體。

對于一個問題，如果你有太多的假設(shè)，很可能會走向一個錯誤的方向，導(dǎo)致不必要的、復(fù)雜的解決方案。一定要精簡假設(shè)來生成好的解決方案。（可見架構(gòu)工作也是一門藝術(shù)）

“搖動”你的架構(gòu)設(shè)計：為了讓架構(gòu)設(shè)計更加簡單，可以從多個角度去審視解決方案，不但要以自頂向下的方式思考，還要自底向上的方式再來一遍， 如果你有數(shù)據(jù)流或者業(yè)務(wù)流程，先從左向右看，然后再從右往左看。

經(jīng)常問自己：“在一個理想的環(huán)境中，架構(gòu)設(shè)計會是怎么樣呢？” ? “如果是那些大公司，它們會怎么做呢？” 這些問題會促使你減少假設(shè)。

退后一步：經(jīng)常長時間的密集討論，通常會得到一個高度復(fù)雜的設(shè)計，你絕對不能把它們當(dāng)作最終結(jié)果，退后一步，從抽象的級別看看全局的圖景，這設(shè)計還是有意義的嗎？??

有時候停止討論，第二天再繼續(xù)會有幫助，至少我的大腦需要時間來處理這些信息，然后提出更好的，更優(yōu)雅的，更簡單的方案。

分而治之：將大問題分成小塊兒，逐個解決，然后看看小塊兒解決方案能不能匹配起來。

重構(gòu)并不邪惡：如果找不到更好的設(shè)計，從一個復(fù)雜的解決方案開始也是可以的。如果后面遇到了問題，你需要回過頭來再想一想，重構(gòu)并不是邪惡的，但是再開始重構(gòu)之前要確保 ：

(1）足夠的自動化的測試用例，保證系統(tǒng)的功能不被破壞

(2)? 獲取利益相關(guān)者的認可。

07代碼

即使是貴為企業(yè)級架構(gòu)師，也就是抽象級別最高的架構(gòu)師，你也得知道程序員日常工作在做些什么。否則你會遇到兩個問題：

(1) ?開發(fā)人員不會接受你的想法、說辭

(2) ?你不會理解開發(fā)人員面臨的真正挑戰(zhàn)和真正的需要。

做一個副業(yè)項目：目的是嘗試新的技術(shù)和工具，以了解當(dāng)前和將來的開發(fā)方式。閱讀一些教程確實不錯，但僅僅是“書本”知識。只有自己親自嘗試一遍，體驗一遍，你才能獲得真正的經(jīng)驗：它為什么好？為什么差？你和一門技術(shù)呆的時間越長，你的體驗就會越多，就越能幫助你做出好的決策。

找到正確的技術(shù)來嘗試：你不可能嘗試所有的東西，我最近發(fā)現(xiàn)了ThoughtWorks的技術(shù)雷達，它們把技術(shù)，工具，平臺，語言和框架分為四類：采用，嘗試、評估和保留。

采用的意思是“適合企業(yè)采用”。

實驗指的是“企業(yè)可以在一個風(fēng)險可控的項目中嘗試”

評估的意思是“研究下如果對企業(yè)產(chǎn)生影響”

暫緩意思是“謹慎推行”

通過這種分類，你就可以找到你想嘗試的新技術(shù)了。

08文檔

Clean Code：簡潔優(yōu)雅的代碼是最好的文檔，架構(gòu)師一定得能區(qū)分開什么是好代碼，什么是壞代碼。有一本很好的書來介紹好代碼和壞代碼：

在可能的時候盡量自動生成文檔：對于一些較為詳細的文檔，由于系統(tǒng)變化迅速，很難及時更新，所以盡可能自動生成文檔：如果你是Model Driven的話可以從定義文件中自動生成文檔，SWagger 和RAML都是很好的起點。

該多就多，該少就少：無論是什么文檔，在同一時刻只應(yīng)該把注意力放在一件事情上，只包含這件事情的必要信息，額外的信息應(yīng)該保留在附錄中，因為大量的文字是很難閱讀和理解的。?仔細看看你的文檔，問問自己：“為了理解整個東西，是不是所有的信息都在其中了？” ,“哪些信息是必須的，哪些是可以忽略的？”

09溝通

根據(jù)我的觀察，這是最被低估技能，如果你在設(shè)計方面特別出色，但是卻無法和別人溝通，你的想法就沒啥影響力，很可能失敗。

演講：向一個小組或大組做演講是一個架構(gòu)師常見的工作，如果你剛開始覺得不舒服，可以從你的最好的朋友開始，慢慢擴大的更多的人，這件事只能通過不斷地實踐來學(xué)習(xí)， 是個需要花費時間的過程，還需要離開舒適區(qū)，所以要保持耐心。

找到正確的溝通級別：不同的人看待事物的角度是不同的，所以你需要在他們的級別和他們交流。比如開發(fā)人員對技術(shù)細節(jié)感興趣，經(jīng)理更傾向于知道哪個選項更加省錢。

所以在溝通之前，你要看看你想交流的東西是不是在合適的級別，包括抽象度，內(nèi)容，目標(biāo)，動機等

經(jīng)常溝通：如果無人知曉，一個出色的架構(gòu)毫無意義，要經(jīng)常溝通你的架構(gòu)設(shè)計以及背后的想法，定期在每個組織級別（小組，部門，公司）進行溝通，安排和開發(fā)人員，架構(gòu)師，管理人員的會議，展示你的架構(gòu)思路。

保持透明：定期溝通只能部分緩解缺少的透明度，你還得確保決策背后的原因透明化，特別是對那些不參加決策的過程的人，他們很難理解為什么要這么做，有什么理由。

隨時準(zhǔn)備好做一個演講：總會有人問架構(gòu)師問題，你也想快速地給出正確答案，這該怎么辦呢？你可以把最重要的PPT挑出來，放在一起，隨時展示并且給他們做展示，避免在一堆資料中找來找去，那樣會浪費太多時間。

10估算和評估

理解基本的項目管理原則：作為架構(gòu)師或者首席開發(fā)，你經(jīng)常會被要求對你的設(shè)計進行估算：多長時間能完成？需要多少人？需要什么技能？

剛開始，你可以提供粗略的估算：幾天，幾個月。請記住估算的時間可不僅僅是編碼實現(xiàn)，要有需求分析，測試，改正Bug。因此你需要知道軟件開發(fā)過程中的各個步驟。獲得更好估算的一個方法是基于歷史數(shù)據(jù)給出預(yù)測。如果你沒有歷史數(shù)據(jù)，可以試試COCOMO方法，如果你在做一個敏捷項目，這本書非常有幫助：

評估架構(gòu)：作為一個架構(gòu)師，你應(yīng)該能夠架構(gòu)設(shè)計在當(dāng)前和未來上下文中的適應(yīng)性，這件事不容易，你可以準(zhǔn)備一組問題來對架構(gòu)設(shè)計進行“質(zhì)詢”，例如：

(1)?設(shè)計實踐: 架構(gòu)遵循了哪些模式？是否正確地被使用了?是否有清晰的設(shè)計和關(guān)注點分離?

(2)?開發(fā)實踐: 制定代碼規(guī)范了嗎？被遵循了嗎？代碼有版本控制嗎

(3) 質(zhì)量保證: 自動化測試的覆蓋率如何? 有靜態(tài)代碼分析到位了嗎? Peer review做到位了嗎?

(4)?安全: 架構(gòu)設(shè)計中有哪些安全概念? 內(nèi)置安全性如何? 滲透測試和自動化安全分析是否做到位？是否定期使用？

11平衡

質(zhì)量是有代價的：前面聊過系統(tǒng)質(zhì)量和非功能性需求，如果你在架構(gòu)設(shè)計上做得過度，就會增加開銷，降低開發(fā)的速度。你需要平衡架構(gòu)設(shè)計和功能需求，過度設(shè)計應(yīng)該被避免。

解決相互矛盾的目標(biāo)：一個經(jīng)典的例子就是短期目標(biāo) vs 長期目標(biāo)。項目通常傾向于構(gòu)建最簡單的方案，而架構(gòu)師腦海中有長期的愿景。通常，簡單的方案不適合長期的目標(biāo)，并且有可能被丟棄（沉沒成本）。為了避免走向錯誤的方向，應(yīng)該注意兩件事情：

(1) 開發(fā)人員和業(yè)務(wù)人員都需要理解長期的愿景及其收益。

(2) 負責(zé)預(yù)算的經(jīng)理也需要參與其中，了解財務(wù)影響。

沖突管理：由于團隊有著不同背景，沖突難免發(fā)生，為了找到一個相互能接受的、平衡的解決方案，架構(gòu)師需要充當(dāng)粘合劑，來解決這些沖突。關(guān)于溝通的理論，我是從Schulze von Thun的Four-Ears Model開始的：

12咨詢和指導(dǎo)

擁有愿景 ：不管你是在一個什么樣的項目中，不管是傳統(tǒng)的瀑布模型還是敏捷模型，你必須需要有一個愿景，也就是你想獲得的短期和長期目標(biāo)，并且清晰地傳遞給團隊成員。

由于不可能一下子達成所有的目標(biāo)，我通常傾向于建立成熟度模型，讓團隊清楚地得知我們當(dāng)前處于哪一級別。開發(fā)有很多方面，得使用不同的成熟度模型，例如開發(fā)實踐成熟度模型，持續(xù)交付成熟度模型。這些模型的每個級別都有清晰的定義，團隊可以輕松地度量自己在什么級別。

對于持續(xù)交付，我個人傾向于這個模型

建立社區(qū)：例如，把JavaScript程序員和架構(gòu)師組織起來，每個月討論一次，主題可以是如何解決過去和現(xiàn)在的技術(shù)挑戰(zhàn)，新的技術(shù)和方法。架構(gòu)師可以分享、討論他們的愿景，程序員可以分享他們的經(jīng)驗，這樣的會議能幫助建立一個更強大的團伙，對企業(yè)和個人都極具價值。

進行開誠布公的討論：誤解和模棱兩可的根源是缺乏溝通，所以你可以安排一個固定的時間段，如每周30分鐘，和同伴交換一些熱門的話題，什么都可以討論，不用刻意安排討論的議程?？梢援?dāng)場解決一些小事，對于復(fù)雜的主題，安排后續(xù)的跟進。

13營銷

你的想法很棒，并且和大家做了很好的溝通，但是沒人愿意去做，那可能是缺乏了營銷的技巧。

激勵并說服：公司是怎么說服你購買他們產(chǎn)品的？他們肯定展示了價值和好處，但不僅如此，他們還做了漂亮的包裝，使其盡可能地容易消化

(1)原型：帶界面的原型非常直觀，會很吸引人。有很多創(chuàng)建軟件原型的工具，如果你喜歡SAP的話可以事實build.me ，使用它可以輕松快速地創(chuàng)建漂亮的UI5應(yīng)用。

(2)?視頻: ?除了無聊的PPT之外，用一個視頻可以更好地展示你的想法。但是請不要過度營銷，從長期看，內(nèi)容為王，如果你滿嘴跑火車，損傷的是你的聲譽。

捍衛(wèi)你的想法并且堅持不懈：如果你真的對自己的想法深信不疑，你應(yīng)該捍衛(wèi)它，為之戰(zhàn)斗，這是非常必要的，因為具備長期目標(biāo)的架構(gòu)決策是不容易被人接受的：開發(fā)人員不喜歡它因為開發(fā)起來太難， 經(jīng)理不喜歡它因為短期來看代價太高。所以堅持不懈地去說服是你的本職工作。

找到同盟軍：獨自去建立并且執(zhí)行你的想法幾乎是不可能的，你需要盟友的支持來說服別人。這時候需要使用你的社交網(wǎng)絡(luò)，如果你還沒有的話，馬上去建吧！

你可以先去和那些具備開放心態(tài)的同事去談你的想法， 如果他們喜歡（或者部分喜歡），當(dāng)別人問起的時候，他們很有可能會支持你：X的想法很有趣。? 如果他們不喜歡你的想法，問問為什么，你是不是漏掉了什么東西？你的故事不夠吸引人？

下一步就是找到具備決策權(quán)力的盟友，請求他進行一個開放的討論，如果你害怕這種討論，你需要反思一下，是不是應(yīng)該離開舒適區(qū)了。

重復(fù)它，相信它：研究顯示重復(fù)的展示一個觀點會使人們相信這是一個普遍的觀點，即使該觀點僅僅來自一個人。如果你經(jīng)常發(fā)過某個消息，更容易說服別人。但是要當(dāng)心：應(yīng)該明智地使用這種策略，因為它可能適得其反。

關(guān)注我，了解更多??????