架構師成長之路 2 --架構師必備技能（目標）
分享一下我老師大神的人工智慧教程！零基礎，通俗易懂！http://blog.csdn.net/jiangjunshow
也歡迎大家轉載本篇文章。分享知識，造福人民，實現我們中華民族偉大復興！
前言："比你牛B的人比你還努力,你有什麼資格不去奮鬥"
哲學家常思考的問題：" 我是誰？"" 我從哪裡來？"" 要到哪裡去？不只是哲學家，我想每個人都有自己對這三個問題的認知。如果我們要成為架構師，我們自己要面臨的三大問題：結合知乎（https://www.zhihu.com/question/19558112）找準自己定位：我是誰？在哪裡？怎樣做好架構師：我要做什麼？如何搭建架構師知識體系：我該怎麼做？這裡面就是做事方法論：目標（我要做什麼），方法（計劃）（我該怎麼做）, 執行/行動
再來看看架構師該具備什麼能力才能成為一家公司中的靈魂人物：
1、技術實力：每個好架構師都是NB的程式設計師
總結：游泳教練，必定游泳水平好，因為這些都是實踐性很強的工作。書上學來終覺淺，絕知此事要躬行。
這一點毋庸置疑，如果不是寫過N年程式碼的優秀程式設計師，一定不是好的架構師。“架構師”這是一個聽上去比較虛的職位，它的主要價值在於“落地”的過程
1)、解決解決方案：產品團隊要做一個產品，架構師要幫助團隊把技術可行性，技術方案權衡取捨一一剖析清楚；
2)、架構設計和技術實現步驟：技術方案權衡取捨出來了，架構師要設計整體的技術實現步驟，這個過程一定是和團隊其他成員一起完成的，常見的實踐是，1到2個核心成員出一個初稿，然後大家討論完善；
3)、編寫核心模組：技術實現步驟出來了，架構師要和開發團隊一起，進行編碼，可能架構師不一定細究到任何細節，常見的實踐是，系統最困難最核心最關鍵的部分往往由架構師親自操刀；
4)、部署上線和完善流程：系統初版實現了，架構師要和開發團隊、測試團隊、運維團隊一起，
在專案的過程中，架構師至少一半以上的時間是和開發團隊一起進行的，好的架構師不能將實施細節拋之腦後，更直白一些，他要通過撰寫程式碼的方式來指導團隊其他成員理解和實現架構中的細節。
反面的例子是，專案失敗後，架構師反饋“團隊的技術能力不夠”，團隊反饋“這是一個一行程式碼也不會寫的大忽悠”。
2、業務理解和抽象能力：駕馭概念的技能是最高潛力
總結：抽象能力是善於把實物概念化並歸類。
業務理解：架構師需要理解業務，並轉換為可被研發理解的實現方案，因此業務理解能力是架構師的必備技能。
通常來說一個資深的業務架構師，對業務有足夠的敏感度和深入的認知和積累，能夠清楚地知道自己的設計能給公司帶來多大的業務影響，應該能大概預判業務未來的發展趨勢，以便在系統的可擴充套件性上留好一定的空間，所以也會很自然的出現有些業務架構師做著做著就乾脆轉為PD型別的角色。
抽象能力：是通過對業務的理解轉換為系統實現的模型，這顯然也是重要的能力，抽象很多時候也承擔了分解清楚多個團隊的職責，分工清晰化。“邏輯思維，抽象思維”比“編碼的時間”對架構師而言更為重要，如果你不能讓某個非IT人員明白某個概念在說什麼，這個架構師註定也是失敗的
邏輯思維不用展開多說，程式設計師的程式碼都是邏輯，如果XXX就YYY，如果AAA就BBB，缺乏良好的邏輯思維能力基本不可能成為好的架構師，甚至好的程式設計師。
抽象思維又分兩點，一個是將實在的事物概念化，一個是將模糊的感覺數量化。一個蘋果，抽象為質量、大小、顏色、形狀、味道等，這是概念化，是架構師的必備思維。至於質量、大小、顏色、形狀、味道如何轉變成數字來描述，這也是架構師必備的思維。
比如面對一個大型的B2C網站，能夠迅速抽象為採購->運營->前臺搜尋->下單->履單這幾大塊，對系統分而治之，庖丁解牛，早已目無全牛。
有了上述兩點，架構師能將一個“虛”的架構概念描述清楚。
3、設計能力：前瞻性的設計眼光，站在技術的山頂向前眺望
鐵打的程式設計師，流水的技術。程式設計師的開發生涯可能長達幾十年，但一門技術的平均壽命卻不長。因此作為程式設計師們的技術領袖，架構師必須有 很好的技術前瞻性，要先於大家瞭解到最新的技術。
架構是過程，並非結果: 架構是架構師洞察內在結構、原則、規律與邏輯的過程，架構師要做到清晰理解系統，以及簡潔描述，這是分析整合的能力。
一個架構師必須具備極強的分析能力，要做到根據產品宗旨和目標，分析清楚產品定位以及產品業務，再整合利用現有的技術領域，找出最佳方案，實現產品概念。
架構師與技術高手的區別在於，架構師不僅侷限於如何呼叫、如何併發等架構細節（技術高手對這些也非常熟練），還跳出三界，考慮未來問題和潛在風險的應對之道。
一名合格的架構師設計出來的架構是要有前瞻性的，要為了將來的組織能力更上一個臺階而設計， 滿足當下需求並能夠適當擴充套件，是遵循架構設計的系統實現要關注的事情，系統是多樣的，架構不是，系統是演化出來，架構不是。
要培養自己的技術前瞻性，首要是學好英語（不多屆時了，希望未來最先進的技術都首先從國內誕生），看懂外文技術文章，能與業界專家溝通交流，學習別人的實踐方案。
反面的例子是，成天將技術前言的名詞掛在嘴邊，大談“雲端計算，SaaS”這些東西，天天吹水，而落不了地（有可能他自己也搞不清概念如何落地）。
技術前瞻性還提現在對新技術的選型上，哪些東西適合自己團隊，哪些不適合。學習成本、維護成本、硬體成本、潛在風險等等都是架構師需要考 慮的。
架構師在自己所處的領域肯定了解頗深，未來本領域技術該如何發展，應該有自己的理解。也會對未來技術的發展有所期盼，有自己的見解。當然這屬於比較發散的想法，個人有個人的目標。
4、技術深度：透過問題看本質，解決問題和繞開問題
總結：透過問題看本質則是由虛到實，往深層次地挖掘
看到問題的本質，是架構師必須具備的素質。
例子1：菜鳥程式設計師的如此寫php：
echo $_GET['username'];大部分人知道這個出現安全隱患。一般人使用htmlspecialchars解決問題就可以了。但問題的本質是什麼？可以從更深的層次去理解：
比如echo是如何執行的？在什麼時候執行的？哪些字元可能導致安全問題？htmlspecialchars為什麼能解決這個問題？它真的解決這個問題了麼？
那麼他將會一點一點的進步，逐漸成為一個合格的程式設計師。
再比如看到一段java程式碼，知道它在JVM如何執行；一個跨網路呼叫，知道資料是如何通過各種介質到達目標(作業系統核心/網絡卡埠/電磁介質等）。透過問題看本質使架構師能夠敏銳地發現底層之真實，系統性端到端地思考問題，識別木桶的短板並解決之。
什麼是本質？將世界萬物理解為原子，將整個網際網路理解成0和1，這倒的確是非常本質了，不過並不能解答任何問題。從問題看本質，實質上是一個從表層逐步深入的過程。在架構師面對一個使用者需求時，這個“使用者需求”是非常表層的——比如說，一個自動遠端備份資料庫的功能。而架構師的主要工作，就是把這樣的“業務需求”翻譯成“技術需求”。這個過程一方面需要通過抽象思維將使用者需求提煉為啟動、讀取、儲存、中斷處理等模組，而另一方面則需要看到更深層次的網路、作業系統、硬體等方面，以及其可靠性、穩定性、適用性、安全性等問題。
架構師要有將“業務需求”轉化為“技術需求”的能力，這是一個本質的挖掘。例如，業務層面看到的是一個“電子商務網站系統”，架構師看到的是一個多人線上，併發交易，需要保證資料一致性的站點、服務、資料系統，功能、效能、擴充套件性、維護性、安全性、可用性這些字眼會慣性的蹦到架構師的腦子裡。
架構師之所以是架構師，他在龐大系統的面前，仍然能夠敏銳發現其底層之真實，這就需要，他有多年多領域知識和經驗的沉澱。
5、技術廣度：要成為百科全書式的智者
總結：1、全面瞭解各個層面的知識。2、瞭解主流公司的系統設計，碰到實際問題，很快有多種方案可供評估。
首先，作為一名卓越的程式設計師，架構師肯定不欠缺開發方面的知識。從架構到方法論，從資料處理到安全監控。可以說IT開發層面上，架構師可以做到爐火純青的地步。但是這僅僅是一名卓越程式設計師的能力級別，離架構師那還有很大的一段距離。
架構師作為一名技術領袖，需要通過散發知識的光芒來溫暖開發團隊，如果只一個領域內的知識爛熟於胸，那也僅僅是一名技術高手。要想更進一步，需要對APP層面、服務層面、資料層面均要了解（系統分層），要對研發、測試、運維、安全也要有所瞭解（職能），上要對介面，下要對原理（介面與實現）都有所瞭解，甚至，要在多個業務領域都有所涉獵。
有的程式設計師也會說，如果多學習跨領域、跨學科的東西，會不會成為什麼都懂，但什麼都不精的人？其實在這裡的跨領域，並不是要求大家都成為每個領域的專家。最重要的是有一門敲門磚，學習的引子。如果開發一套金融系統，對於財務結算以及處理方法都不瞭解，那別說是勝任架構師的任務，連普通程式設計師的工作也不可能做好。假設大家工作一段時間後，對某領域很瞭解，但由於工作變動的緣故，到其他公司後，開發的領域完全不會。這裡就要用到跨領域知識學習的能力了，需要大家樣樣都要知曉。
談到跨領域學習，知識面廣似乎是最好實現的目標，只要博覽群書，加上高中之前各學科紮實的基礎，相信大多數程式設計師本身就具備一定的跨領域學習的能力。但想成為真正的百科全書式的智者，恐怕不光是簡單覺得眼熟就行。在條件允許的情況下，程式設計師其實可以去參加一些其他領域的專業考試。比如參加會計資格證的考試，抑或其他專業中較初級的考試。這樣的經歷，主要還是在於“以學促考”，通過一定的壓力讓自己能鑽進去學習。
初級架構師所害怕的，是跳出自己的“獨門絕技”，在一定程度上說，在一定深度之內成為一個“雜家”也沒什麼不好。
6、溝通能力：善於溝通的技術領袖
總結：溝通能力確保各方對架構達成共識，願意採取行動
架構師必須參與專案開發全過程，包括確認需求、系統分解、架構設計、技術選型、制定技術規格說明、系統實現、整合測試和部署各階段，在這一系列過程中，架構師會與各部門溝通交流。
一個產品會有多部門合作，架構師在其中的溝通極為重要，直接影響產品進度與質量。架構師不僅要與開發人員溝通，也要和專案經理、分析人員甚至使用者溝通，來實現產品的各種可能性。
架構師和專案經理，對溝通能力的要求都很高，很多網際網路公司甚至直接由架構師擔任專案經理的角色。這兩個角色其實還是有所偏重的，專案經理更傾向於與客戶的交流，跨團隊的協作與交流，架構師主要偏向技術團隊內部的溝通與交流，純技術上的溝通。
如何成為一名“善於溝通”的架構師呢？在目標清晰的前提下：
首先做到平和，不能將自己所在象牙塔上，頤指氣使的發號施令，這樣的態度必然遭恨，大家都是技術人員，只是分工不同，為何要受你的氣呢？
其次，架構師要有一定的繪圖能力。人對圖形的理解遠大於對文字的理解，一個層次圖，一塊小白板，幾隻筆，真的這麼容易把問題描述清楚麼？
做到人性化的溝通，需要我們在平時就進行培養。寫出大部頭的架構書，有的時候並沒有用VISIO畫出的簡單架構圖好理解。人對圖形理解遠遠大於對文字的理解，直觀簡單的UML圖可以極大的方便程式設計師理解架構師的意圖。
其次，可以召開小範圍的技術人員會議，大家一起來討論，一起理解架構師真正的意圖。甚至就是一塊小白板，幾支筆就能把問題擺清楚，講明白，統一意見後的團隊必然幹勁十足，再不會出現互相推諉的情況。
架構師就相當於一支球隊的主教練，如何將自己佈置的戰術交到執行的球員，也就是開發人員的腦袋裡，是關乎勝利的關鍵。那麼怎樣才能成為一名能說會道的程式設計師呢？
在一般人的印象裡，程式設計師都是一群略顯呆滯，溝通能力不強的技術狂人。邏輯思維非同常人，但就是倒不出來。有些人通過找女朋友作為旁證，連經濟適用男中的定義原型都是IT人士，月薪4000以上，不善言談，最後娶一剩女為妻。看來我等程式設計師，真的只能被人如此定義了。雖說架構師技術層面上的東西與前例不可同日而語，但是也看到溝通能力上，程式設計師還有很大的發展空間。
7、系統性的思考：權衡利弊，只有合適沒有喜歡
總結：系統性地思考：平衡取捨能力確保架構在現有資源約束下是最合理的，理想最終照進現實。
合格的架構師都是好的戰略家，前瞻性眼光是他們起碼的要求，而系統性的思考則是將這些前瞻性眼光落地的必備素質。
架構既看重前瞻，又看重落地，落不了地的架構只是空中樓閣，所以，如何將架構落地，考量的就是一名合格架構師的綜合素質和系統思考的能力。
因為架構的規劃和落地依附於現有的環境因素很多且不可重現，所以，合格的架構師要能夠儘可能多的將對架構有過多權重影響的因素考量進來，然後做權衡，抓住重點因素，最後集中兵力重點突破。
比如，是採用傳統的Monolith架構體系，還是時下風靡的微服務架構體系，你要能夠從團隊人員層次和能力，組織和公司的發展現狀，時機等重點因素中做出權衡，你沒法通過資料建模的手段去完成這個工作，你能依靠的，只有你的綜合素質和系統思考能力：
從時機（Timing）上說，如果單個應用結點就可以滿足業務發展需求，那麼，就沒有必要上微服務，否則反而憑空增加了整個交付鏈路的負擔；
如果團隊的成員能力還不足以支撐起微服務體系相關的所有工具化，服務化和平臺化建設，那麼微服務架構也不是最合適的方向；
如果公司業務還處在四處拼殺，生死未卜的時候，公司的現狀也不會允許你去搞各種完善的基礎性建設，活下來才是第一位的；
對於架構師來說，你要關注的不是“點”，而應該關注的是儘可能多的“點”，進而是連線點的線，到面，甚至到體。
內容總結出處：
http://developer.51cto.com/developer/top10Architect/#rd?sukey=66d4519b2d3854cd535bf0462edeb1d5721720363e90d6701c95530c7d8a78ac6203d54a7f38501ac7386ff1f65d9356
王福強：“一名架構師的自我修養”感謝您的支援，我會繼續努力的! 掃碼打賞，你說多少就多少
4、系統性的思考：權衡利弊，只有合適沒有喜歡
總結：系統性地思考：平衡取捨能力確保架構在現有資源約束下是最合理的，理想最終照進現實。
合格的架構師都是好的戰略家，前瞻性眼光是他們起碼的要求，而系統性的思考則是將這些前瞻性眼光落地的必備素質。
架構既看重前瞻，又看重落地，落不了地的架構只是空中樓閣，所以，如何將架構落地，考量的就是一名合格架構師的綜合素質和系統思考的能力。
因為架構的規劃和落地依附於現有的環境因素很多且不可重現，所以，合格的架構師要能夠儘可能多的將對架構有過多權重影響的因素考量進來，然後做權衡，抓住重點因素，最後集中兵力重點突破。
比如，是採用傳統的Monolith架構體系，還是時下風靡的微服務架構體系，你要能夠從團隊人員層次和能力，組織和公司的發展現狀，時機等重點因素中做出權衡，你沒法通過資料建模的手段去完成這個工作，你能依靠的，只有你的綜合素質和系統思考能力：
從時機（Timing）上說，如果單個應用結點就可以滿足業務發展需求，那麼，就沒有必要上微服務，否則反而憑空增加了整個交付鏈路的負擔；
如果團隊的成員能力還不足以支撐起微服務體系相關的所有工具化，服務化和平臺化建設，那麼微服務架構也不是最合適的方向；
如果公司業務還處在四處拼殺，生死未卜的時候，公司的現狀也不會允許你去搞各種完善的基礎性建設，活下來才是第一位的；
對於架構師來說，你要關注的不是“點”，而應該關注的是儘可能多的“點”，進而是連線點的線，到面，甚至到體。
給我老師的人工智慧教程打call！http://blog.csdn.net/jiangjunshow
