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

我事先給一位同學看了一下，他說：當個架構師太難了吧，又要精通技術，還得會溝通，平衡，營銷..... 我還是爭取做個技術專家吧！

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

01 什么是軟件架構師

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

軟件架構師是一個軟件專家，他可以做出高層的設計決定，規(guī)定技術標準，包括編碼標準，工具和平臺 -- Wikipedia

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

02 架構的級別

架構可以在不同的抽象級別上完成， 不同的級別要求不同技能，有很多分類標準，我最喜歡的是這三個級別：

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

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

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

有時候，架構師被看作不同利益相關者之間的粘合劑，比如：

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

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

技術領域：集成不同的技術和應用。

03 軟件架構師的日常活動

為了理解軟件架構師需要哪些技能，我們得先來看看架構師的日常活動

• 確定開發(fā)的平臺和技術
• 確定開發(fā)標準和規(guī)范：編碼標準，工具，評審流程，測試方法等
• 根據需求，設計系統(tǒng)并且做出架構設計決定
  ?
• 把架構設計和決定文檔化，和團隊溝通
• 把高層的設計變成底層設計
• 檢查、評審架構設計和代碼，比如看看確定的模式和代碼標準是否正確施行
• 和其他架構師、利益相關者協(xié)作
  ?
• 指導開發(fā)人員

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

軟件架構師所需的重要技能

根據我的經驗，閱讀的書籍，以及參與的討論，我可以列出這10個技能，每個架構師都必須具備：

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

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

04 設計

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

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

比如書中描述的MVC模式被應用在很多領域，也是很多新模式如MVVM的基礎。

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

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

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

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

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

分析、理解那些應用良好的模式：看看你當前使用的框架，例如Angular， 你可以研究很多以及付諸實踐的模式，如觀察者?？纯此窃趺丛诳蚣苤惺褂玫?，為什么要這么使用。如果你愿意投入更多的精力，那就深入源代碼看看它是如何實現的。

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

05 決策

架構師需要能夠做出架構決定，引導項目和組織走在正確的方向。

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

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

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

所以一定要和你的同伴明確你承擔的職責和你的角色。作為低級別的架構師，你可以提出對高層架構的建議，但是不要擅自做主。我建議要經常和同伴審視那些關鍵的架構決定。

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

06 簡潔

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

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

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

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

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

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

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

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

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

(2)  獲取利益相關者的認可。

07 代碼

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

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

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

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

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

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

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

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

暫緩意思是“謹慎推行”

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

08 文檔

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

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

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

09 溝通

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

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

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

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

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

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

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

10 估算和評估

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

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

評估架構：作為一個架構師，你應該能夠架構設計在當前和未來上下文中的適應性，這件事不容易，你可以準備一組問題來對架構設計進行“質詢”，例如：

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

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

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

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

11 平衡

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

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

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

(2) 負責預算的經理也需要參與其中，了解財務影響。

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

12 咨詢和指導

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

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

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

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

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

13 營銷

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

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

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

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

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

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

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

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

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