這是很多程式設計師的疑問，最近看到Kai Niklas講架構師的一篇文章，其中的真知灼見引起了我的強烈共鳴，尤其是後面的非技術部分。翻譯過來（略有刪減），分享給大家。英文文章請點擊」閱讀原文「。
我事先給一位同學看了一下，他說：當個架構師太難了吧，又要精通技術，還得會溝通，平衡，營銷 我還是爭取做個技術專家吧！
捫心自問，我這個架構師在很多方面也做得遠遠不夠，繼續學習吧！如果你的未來職業目標是架構師，強烈建議仔細閱讀並收藏。
在我們一頭扎入細節之前，我們先得知道軟體架構和架構師到底是什麼：
軟體架構師是一個軟體專家，他可以做出高層的設計決定，規定技術標準，包括編碼標準，工具和平臺 -- Wikipedia
軟體架構是一個系統最基本的組織方式，由其組件，組件之間的關係，組件和環境的關係表達出來。也包括決定設計和系統演化的原則。--Handbook of Software Architecture
架構可以在不同的抽象級別上完成， 不同的級別要求不同技能，有很多分類標準，我最喜歡的是這三個級別：
Application Level （應用級別）：架構的最低級別，專注於單個應用，有非常具體的設計，溝通通常局限在開發團隊
Solution Level （解決方案級別） ：架構的中間層，需要關注幾個應用來實現一個商業的需求，有部分高層的設計，但大多數還是具體的設計，溝通需要跨越多個開發團隊。
Enterprise Level (企業級別)：架構的最高級， 關注多個解決方案，這一層的設計比較抽象，需要解決方案架構師和應用架構師去細化。溝通跨越整個企業組織。
有時候，架構師被看作不同利益相關者之間的粘合劑，比如：
為了理解軟體架構師需要哪些技能，我們得先來看看架構師的日常活動
注: 架構設計是一個持續的活動，所以這些活動會一遍一遍地完成。
根據我的經驗，閱讀的書籍，以及參與的討論，我可以列出這10個技能，每個架構師都必須具備：
設計, 決策，簡化, 編碼, 文檔, 溝通, 估算, 平衡, 諮詢, 營銷
我們一個個來說，對每個技能我都會列出一些我的見解，你應該採取的行動，以便在這個技能領域持續提高。
是什麼造就了好的設計？這可能是最重要，並且最具挑戰性的問題，讓我們先從理論開始。
理解基本的設計模式：為了開發一個可維護的系統，模式絕對是架構師最重要的工具之一，使用模式，你可以復用設計來決定那些通用的問題。「四人幫」的《設計模式：可復用的面向對象軟體基礎》是每個開發人員的必讀書籍。儘管過去20多年了，模式依然是軟體架構的基本單元。
比如書中描述的MVC模式被應用在很多領域，也是很多新模式如MVVM的基礎。
深入挖掘模式和反模式：理解了基本的「四人幫」模式以後，你需要把你知識擴展到更多的軟體設計模式中，或者根據自己的興趣，深入研究，例如Java併發模式。
在應用程式的集成領域， 我最喜歡的是《企業集成模式》，這本書適用於各種領域，只要兩個應用需要交換數據，不管是很古老的基於文件的交換還是現代的微服務架構，都可以參考本書。
了解軟體質量的度量方式：我們希望我們的系統是可以維護的、可靠的、安全的、可以測試的、可以擴展的、可用的. 為了達成這些目標，必須要把系統架構設計好。你可以參考這個：
理論很重要，實踐更加重要，否則你就會變成一個象牙塔架構師。
不斷嘗試和理解不同的技術棧 ： 我認為這是成為架構師非常重要的事情， 你很難從抽象的PPT中學到真東西，你得嘗試不同的、新的技術棧，親自感受一下它帶來的好處和引發的「疼痛」。另外也可以嘗試不屬於你所在領域的技術，例如你對SAP R/3 非常擅長，那你應該也試試JavaScript。
分析、理解那些應用良好的模式：看看你當前使用的框架，例如Angular， 你可以研究很多以及付諸實踐的模式，如觀察者。看看它是怎麼在框架中使用的，為什麼要這麼使用。如果你願意投入更多的精力，那就深入原始碼看看它是如何實現的。
保持好奇心，參加一些公司之外的社團活動：比如Java User Group會討論很多主題，從最底層的編碼到高層的架構，我很喜歡這樣的活動，因為它會讓我跳出工作來思考，並且加強個人社交網絡。
架構師需要能夠做出架構決定，引導項目和組織走在正確的方向。
確定優先級：有些決策非常關鍵，如果沒有在早期確定下來，就會出現一些變通的臨時措施，導致後續難以移除，變成維護的噩夢。更差的情況是，程式設計師需要停止工作，等你做出決策。
為了避免這種情況，必須要把這些決策按優先級排序，我建議看一看敏捷軟體開發中非常流行的Weighted Shortest Job First (WSJF) 模型。
了解你的能力：不要在你的能力之外做決定，這非常關鍵，如果你不遵循的話可能會毀掉你架構師的崗位。
所以一定要和你的同伴明確你承擔的職責和你的角色。作為低級別的架構師，你可以提出對高層架構的建議，但是不要擅自做主。我建議要經常和同伴審視那些關鍵的架構決定。
評估多個選項：涉及到決策時，要列出多個選項。在我參與的大多數決策中，都有不止一個可能（好的）選擇。僅僅提供一個選項說明你沒有完成自己的工作，沒法完成決策。各種選項要通過可以度量的事實（如許可證費用，成熟度）而不是個人感情來比較，這樣才能真正完成決策。
要謹記解決問題的奧卡姆剃刀原則：如無必要，勿增實體。
對於一個問題，如果你有太多的假設，很可能會走向一個錯誤的方向，導致不必要的、複雜的解決方案。一定要精簡假設來生成好的解決方案。（可見架構工作也是一門藝術）
「搖動」你的架構設計：為了讓架構設計更加簡單，可以從多個角度去審視解決方案，不但要以自頂向下的方式思考，還要自底向上的方式再來一遍， 如果你有數據流或者業務流程，先從左向右看，然後再從右往左看。
經常問自己：「在一個理想的環境中，架構設計會是怎麼樣呢？」 「如果是那些大公司，它們會怎麼做呢？」 這些問題會促使你減少假設。
退後一步：經常長時間的密集討論，通常會得到一個高度複雜的設計，你絕對不能把它們當作最終結果，退後一步，從抽象的級別看看全局的圖景，這設計還是有意義的嗎？
有時候停止討論，第二天再繼續會有幫助，至少我的大腦需要時間來處理這些信息，然後提出更好的，更優雅的，更簡單的方案。
分而治之：將大問題分成小塊兒，逐個解決，然後看看小塊兒解決方案能不能匹配起來。
重構並不邪惡：如果找不到更好的設計，從一個複雜的解決方案開始也是可以的。如果後面遇到了問題，你需要回過頭來再想一想，重構並不是邪惡的，但是再開始重構之前要確保 ：
(1）足夠的自動化的測試用例，保證系統的功能不被破壞
即使是貴為企業級架構師，也就是抽象級別最高的架構師，你也得知道程式設計師日常工作在做些什麼。否則你會遇到兩個問題：
(2) 你不會理解開發人員面臨的真正挑戰和真正的需要。
做一個副業項目：目的是嘗試新的技術和工具，以了解當前和將來的開發方式。閱讀一些教程確實不錯，但僅僅是「書本」知識。只有自己親自嘗試一遍，體驗一遍，你才能獲得真正的經驗：它為什麼好？為什麼差？你和一門技術呆的時間越長，你的體驗就會越多，就越能幫助你做出好的決策。
找到正確的技術來嘗試：你不可能嘗試所有的東西，我最近發現了ThoughtWorks的技術雷達，它們把技術，工具，平臺，語言和框架分為四類：採用，嘗試、評估和保留。
Clean Code ：簡潔優雅的代碼是最好的文檔，架構師一定得能區分開什麼是好代碼，什麼是壞代碼。有一本很好的書來介紹好代碼和壞代碼：
在可能的時候儘量自動生成文檔：對於一些較為詳細的文檔，由於系統變化迅速，很難及時更新，所以儘可能自動生成文檔：如果你是Model Driven的話可以從定義文件中自動生成文檔，SWagger 和RAML都是很好的起點。
該多就多，該少就少：無論是什麼文檔，在同一時刻只應該把注意力放在一件事情上，只包含這件事情的必要信息，額外的信息應該保留在附錄中，因為大量的文字是很難閱讀和理解的。 仔細看看你的文檔，問問自己：「為了理解整個東西，是不是所有的信息都在其中了？」 ,「哪些信息是必須的，哪些是可以忽略的？」
根據我的觀察，這是最被低估技能，如果你在設計方面特別出色，但是卻無法和別人溝通，你的想法就沒啥影響力，很可能失敗。
演講：向一個小組或大組做演講是一個架構師常見的工作，如果你剛開始覺得不舒服，可以從你的最好的朋友開始，慢慢擴大的更多的人，這件事只能通過不斷地實踐來學習， 是個需要花費時間的過程，還需要離開舒適區，所以要保持耐心。
找到正確的溝通級別：不同的人看待事物的角度是不同的，所以你需要在他們的級別和他們交流。比如開發人員對技術細節感興趣，經理更傾向於知道哪個選項更加省錢。
所以在溝通之前，你要看看你想交流的東西是不是在合適的級別，包括抽象度，內容，目標，動機等
經常溝通： 如果無人知曉，一個出色的架構毫無意義，要經常溝通你的架構設計以及背後的想法，定期在每個組織級別（小組，部門，公司）進行溝通，安排和開發人員，架構師，管理人員的會議，展示你的架構思路。
保持透明：定期溝通只能部分緩解缺少的透明度，你還得確保決策背後的原因透明化，特別是對那些不參加決策的過程的人，他們很難理解為什麼要這麼做，有什麼理由。
隨時準備好做一個演講：總會有人問架構師問題，你也想快速地給出正確答案，這該怎麼辦呢？你可以把最重要的PPT挑出來，放在一起，隨時展示並且給他們做展示，避免在一堆資料中找來找去，那樣會浪費太多時間。
理解基本的項目管理原則：作為架構師或者首席開發，你經常會被要求對你的設計進行估算：多長時間能完成？需要多少人？需要什麼技能？
剛開始，你可以提供粗略的估算：幾天，幾個月。請記住估算的時間可不僅僅是編碼實現，要有需求分析，測試，改正Bug。因此你需要知道軟體開發過程中的各個步驟。獲得更好估算的一個方法是基於歷史數據給出預測。如果你沒有歷史數據，可以試試COCOMO方法，如果你在做一個敏捷項目，這本書非常有幫助：
評估架構：作為一個架構師，你應該能夠架構設計在當前和未來上下文中的適應性，這件事不容易，你可以準備一組問題來對架構設計進行「質詢」，例如：
(1) 設計實踐: 架構遵循了哪些模式？是否正確地被使用了?是否有清晰的設計和關注點分離?
(2) 開發實踐: 制定代碼規範了嗎？被遵循了嗎？代碼有版本控制嗎
(3) 質量保證: 自動化測試的覆蓋率如何? 有靜態代碼分析到位了嗎? Peer review做到位了嗎?
(4) 安全: 架構設計中有哪些安全概念? 內置安全性如何? 滲透測試和自動化安全分析是否做到位？是否定期使用？
質量是有代價的：前面聊過系統質量和非功能性需求，如果你在架構設計上做得過度，就會增加開銷，降低開發的速度。你需要平衡架構設計和功能需求，過度設計應該被避免。
解決相互矛盾的目標：一個經典的例子就是短期目標 vs 長期目標。項目通常傾向於構建最簡單的方案，而架構師腦海中有長期的願景。通常，簡單的方案不適合長期的目標，並且有可能被丟棄（沉沒成本）。為了避免走向錯誤的方向，應該注意兩件事情：
(1) 開發人員和業務人員都需要理解長期的願景及其收益。
(2) 負責預算的經理也需要參與其中，了解財務影響。
衝突管理：由於團隊有著不同背景，衝突難免發生，為了找到一個相互能接受的、平衡的解決方案，架構師需要充當粘合劑，來解決這些衝突。關於溝通的理論，我是從Schulze von Thun的Four-Ears Model開始的：
擁有願景 ：不管你是在一個什麼樣的項目中，不管是傳統的瀑布模型還是敏捷模型，你必須需要有一個願景，也就是你想獲得的短期和長期目標，並且清晰地傳遞給團隊成員。
由於不可能一下子達成所有的目標，我通常傾向於建立成熟度模型，讓團隊清楚地得知我們當前處於哪一級別。開發有很多方面，得使用不同的成熟度模型，例如開發實踐成熟度模型，持續交付成熟度模型。這些模型的每個級別都有清晰的定義，團隊可以輕鬆地度量自己在什麼級別。
對於持續交付，我個人傾向於這個模型
建立社區：例如，把JavaScript程式設計師和架構師組織起來，每個月討論一次，主題可以是如何解決過去和現在的技術挑戰，新的技術和方法。架構師可以分享、討論他們的願景，程式設計師可以分享他們的經驗，這樣的會議能幫助建立一個更強大的團夥，對企業和個人都極具價值。
進行開誠布公的討論：誤解和模稜兩可的根源是缺乏溝通，所以你可以安排一個固定的時間段，如每周30分鐘，和同伴交換一些熱門的話題，什麼都可以討論，不用刻意安排討論的議程。可以當場解決一些小事，對於複雜的主題，安排後續的跟進。
你的想法很棒，並且和大家做了很好的溝通，但是沒人願意去做，那可能是缺乏了營銷的技巧。
激勵並說服：公司是怎麼說服你購買他們產品的？他們肯定展示了價值和好處，但不僅如此，他們還做了漂亮的包裝，使其儘可能地容易消化
(1) 原型：帶界面的原型非常直觀，會很吸引人。有很多創建軟體原型的工具，如果你喜歡SAP的話可以事實build.me ，使用它可以輕鬆快速地創建漂亮的UI5應用。
(2) 視頻: 除了無聊的PPT之外，用一個視頻可以更好地展示你的想法。但是請不要過度營銷，從長期看，內容為王，如果你滿嘴跑火車，損傷的是你的聲譽。
捍衛你的想法並且堅持不懈：如果你真的對自己的想法深信不疑，你應該捍衛它，為之戰鬥，這是非常必要的，因為具備長期目標的架構決策是不容易被人接受的：開發人員不喜歡它因為開發起來太難， 經理不喜歡它因為短期來看代價太高。所以堅持不懈地去說服是你的本職工作。
找到同盟軍：獨自去建立並且執行你的想法幾乎是不可能的，你需要盟友的支持來說服別人。這時候需要使用你的社交網絡，如果你還沒有的話，馬上去建吧！
你可以先去和那些具備開放心態的同事去談你的想法， 如果他們喜歡（或者部分喜歡），當別人問起的時候，他們很有可能會支持你：X的想法很有趣。 如果他們不喜歡你的想法，問問為什麼，你是不是漏掉了什麼東西？你的故事不夠吸引人？
下一步就是找到具備決策權力的盟友，請求他進行一個開放的討論，如果你害怕這種討論，你需要反思一下，是不是應該離開舒適區了。
重複它，相信它：研究顯示重複的展示一個觀點會使人們相信這是一個普遍的觀點，即使該觀點僅僅來自一個人。如果你經常發過某個消息，更容易說服別人。但是要當心：應該明智地使用這種策略，因為它可能適得其反。