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