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

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

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

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

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

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

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

02 架構(gòu)的級(jí)別

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

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

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

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

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

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

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

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

03 軟件架構(gòu)師的日常活動(dòng)

為了理解軟件架構(gòu)師需要哪些技能，我們得先來看看架構(gòu)師的日常活動(dòng)

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

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

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

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

設(shè)計(jì), 決策，簡(jiǎn)化, 編碼, 文檔, 溝通, 估算, 平衡, 咨詢, 營(yíng)銷

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

04 設(shè)計(jì)

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

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

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

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

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

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

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

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

分析、理解那些應(yīng)用良好的模式：看看你當(dāng)前使用的框架，例如Angular， 你可以研究很多以及付諸實(shí)踐的模式，如觀察者。看看它是怎么在框架中使用的，為什么要這么使用。如果你愿意投入更多的精力，那就深入源代碼看看它是如何實(shí)現(xiàn)的。

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

05 決策

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

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

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

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

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

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

06 簡(jiǎn)潔

要謹(jǐn)記解決問題的奧卡姆剃刀原則：如無必要，勿增實(shí)體。

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

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

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

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

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

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

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

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

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

07 代碼

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

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

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

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

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

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

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

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

暫緩意思是“謹(jǐn)慎推行”

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

08 文檔

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

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

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

09 溝通

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

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

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

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

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

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

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

10 估算和評(píng)估

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

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

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

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

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

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

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

11 平衡

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

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

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

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

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

12 咨詢和指導(dǎo)

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

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

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

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

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

13 營(yíng)銷

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

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

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

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

捍衛(wèi)你的想法并且堅(jiān)持不懈：如果你真的對(duì)自己的想法深信不疑，你應(yīng)該捍衛(wèi)它，為之戰(zhàn)斗，這是非常必要的，因?yàn)榫邆溟L(zhǎng)期目標(biāo)的架構(gòu)決策是不容易被人接受的：開發(fā)人員不喜歡它因?yàn)殚_發(fā)起來太難， 經(jīng)理不喜歡它因?yàn)槎唐趤砜创鷥r(jià)太高。所以堅(jiān)持不懈地去說服是你的本職工作。

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

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

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

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