程式設計師如何從菜鳥工程師到高階架構師？
第一時間獲取技術乾貨
踽踽獨行上下求索總是痛苦，如果有良師益友陪伴點撥必能事半功倍。從新手碼農到高階架構師，要經過幾步？要多努力，才能成為為人倚重的技術專家？本文將為你帶來一張程式設計師發展路徑圖，但你需要知道的是，天下沒有普適的道理，具體問題還需具體分析，實踐才能出真知。
架構師的“內功”
《從 0 開始學架構》專欄已經全部更新完畢，我在專欄裡給你講述了我的完整架構設計方法論，包括架構設計的概念、原則、步驟、技巧、模式等，這些內容是我融合多年來的學習、實踐、思考總結得出來的精華。“王婆自誇”一下，專欄就相當於一部《九陽真經》，你按照武功祕籍的方法去修煉，自然能夠比站在村口大樹下打木人樁效率要高得多。然而要成為高手，光知道招式還遠遠不夠，更重要的是內功和判斷，能夠一眼看出對手的弱點或者破綻，知道“什麼時候用什麼招式”“遇到什麼對手用什麼招式”更重要。
以架構設計原則的“合適原則”為例，專欄講述了架構設計要遵循“合適原則”，不要過度設計，這個點非常關鍵，能夠避免架構設計的時候盲目超前設計。但是我們在具體架構設計的時候，到底什麼是“合適”，專欄也無法給出一個明確的標準可以放之四海而皆準去套用，因為“合適”和很多因素有關：業務發展、團隊規模、技術實力、領導的喜好等。此時到底什麼是“合適”就依賴架構師的“內功”了，很有可能同一個團隊，A 架構師認為 X 方案是合適的，B 架構師認為 Y 方案是合適的，原因就在於不同的架構師“內功”不一樣。
我認為，架構師的內功主要包含三部分：判斷力、執行力、創新力，簡單解釋如下：
判斷力： 能夠準確判斷系統的複雜度在哪裡，就像武俠高手一樣，能準確地看出對手的破綻和弱點。
執行力： 能夠使用合適的方案解決複雜度問題，就像武俠高手一樣，能選擇合適的招式或者方法打敗對手。
創新力： 能夠創造新的解決方案解決複雜度問題，就像武俠世界裡，小一些的創新是創新招式，而武學宗師能夠創立新的武學或者心法，例如張三丰創立太極拳一樣。
因此，要成為一個優秀的架構師，就需要不斷地提升自己這幾方面的內功，而這三方面的能力主要來源於經驗 、視野 、思考 。
經驗： 設計過的系統越多、系統越複雜，架構師的內功也就越強，不管是成功的架構，還是失敗的架構，不管是踩坑的經驗，還是填坑的經驗，都將成為架構師內功的一部分。
視野： 掌握的知識和技能越多、越深，架構師的內功也就越強，他山之石可以攻玉，站在巨人的肩膀上會看的更高更遠。
思考： 經驗和視野都是外部輸入，類似於我們吃的食物，但光吃還不行，還要消化，將其變為我們自己的營養，這就是思考的作用。思考能夠將經驗和視野中的模式、判斷、選擇、技巧等提煉出來為我所用，思考也能促使我們產生新的創意和靈感。
結合上面的分析，從程式設計師到架構師的成長之路，總的指導原則是：積累經驗，拓寬視野，深度思考。按照這個總的原則為指導，接下來我們看看從程式設計師到架構師的成長過程中，具體如何實踐。
我把程式設計師到架構師的技術成長之路分為幾個典型的階段：工程師 - 高階工程師 - 技術專家 - 初級架構師 - 中級架構師 - 高階架構師。 雖然總的指導原則是一樣的，但具體的實踐方法有很大差別，如果在正確的階段採取了錯誤的方法，可能會出現事倍功半的問題。
工程師-階段描述
成為一個合格的工程師需要 1~3 年時間，其典型特徵是“在別人的指導下完成開發 ”，這裡的“別人”主要是“高階工程師”或者“技術專家”，通常情況下，高階工程師或者技術專家負責需求分析和討論、方案設計，工程師負責編碼實現，高階工程師或者技術專家會指導工程師進行編碼實現。
成長指導
工程師階段是最原始的“基礎技能積累階段 ”，主要積累基礎知識，包括程式語言、程式設計工具、各類系統的基本使用。以 Java 後端工程師為例，工程師階段需要積累的經驗和技能有：
Java 的語法、基本資料結構的使用。
Eclipse、IDEA、Maven、Linux 命令列等各種工具。
資料庫 CRUD 操作、快取的基本使用等。
業務系統的基本流程。
工程師階段最好的學習方法就是找經典的書籍系統地學習 ，而不要遇到一個問題到網上搜搜然後就解決了事。以 Java 為例，《Java 程式設計思想》《Java 核心技術》《TCP/IP 協議》這類大部頭，一定要完整地看一遍，即使裡面很多內容當前工作暫時用不上。
高階工程師-階段描述
成長為高階工程師需要 2~5 年時間，其典型特徵是“獨立完成開發 ”，包括需求分析、方案設計、編碼實現，其中需求分析和方案設計已經包含了“判斷”和“選擇”，只是範圍相對來說小一些，更多是在已有架構下進行設計。以 Java 後端工程師為例，高階工程師需要完成的工作包括：
MySQL 資料庫表如何設計，是設計成兩個表還是三個表？
是否要用快取，快取的 Key 和 Value 如何設計，快取的更新策略是什麼？
產品提出的需求是否合理？是否有更好的方式來滿足？
成長指導
從普通工程師成長為高階工程師，主要需要“積累方案設計經驗 ”，簡單來說就是業務當前用到的相關技術的設計經驗。以 Java 後端高階工程師為例，包括：表設計經驗、快取設計經驗、業務流程設計經驗、介面設計經驗等。當接到一個業務需求的時候，高階工程師能夠組合這些設計經驗，最終完成業務需求。
高階工程師階段相比工程師階段，有兩個典型的差異：
深度：如果說工程師是要求知道 How，那高階工程師就要求知道 Why 了。例如 Java 的各種資料結構的實現原理，因為只有深入掌握了這些實現原理，才能對其優缺點和使用場景有深刻理解，這樣在做具體方案設計的時候才能選擇合適的資料結構。
理論：理論就是前人總結出來的成熟的設計經驗，例如資料庫表設計的 3 個正規化、面向物件的設計模式、SOLID 設計原則、快取設計理論（快取穿透、快取雪崩、快取熱點）等。
針對技術深度，我的建議還是系統地學習，包括看書和研究原始碼。例如，研究 Java 虛擬機器可以看《深入理解 Java 虛擬機器》、研究 MySQL 可以看《MySQL 技術內幕：InnoDB 儲存引擎》、研究 Memcache 可以去看其原始碼。
針對設計理論，由於涉及的點很多，沒有一本書能夠涵蓋這麼多的設計點，因此更多的是依靠自己去網上搜索資料學習。那我們怎麼知道哪些地方會有設計理論呢？簡單來說，就是假設每個設計環節都有設計理論，然後帶著這種假設去搜索驗證看看是否真的有很熟的設計理念。
技術專家-階段描述
成長為技術專家需要 4~8 年時間，其典型的特徵是“某個領域的專家 ”，通俗地講，只要是這個領域的問題，技術專家都可以解決。例如：Java 開發專家、PHP 開發專家、Android 開發專家、iOS 開發專家、前端開發專家等。通常情況下，“領域”的範圍不能太小，例如我們可以說“Java 開發專家”，但不會說“Java 多執行緒專家”或“Java JDBC 專家”。
技術專家與高階工程師的一個典型區別就是，高階工程師主要是在已有的架構框架下完成設計，而技術專家會根據需要修改、擴充套件、優化架構。例如，同樣是 Java 開發，高階工程師關注的是如何優化 MySQL 的查詢效能，而技術專家可能就會考慮引入 Elasticsearch 來完成搜尋。
成長指導
從高階工程師成長為技術專家，主要需要“拓展技術寬度 ”，因為一個“領域”必然會涉及眾多的技術面。以 Java 後端開發為例，要成為一個 Java 開發專家，需要掌握 Java 多執行緒、JDBC、Java 虛擬機器、面向物件、設計模式、Netty、Elasticsearch、Memcache、Redis、MySQL 等眾多技術。常見的拓展技術寬度的方法有：
學習業界成熟的開源方案，例如，Java 開發可以去學習 Redis、Memcache、Netty 等，Android 開發可以去研究 Retrofit、Fresco、OkHttp 等。
研究業界的經驗分享，例如 BAT、FANG 等大公司的經驗，可以通過參加技術大會等方式去近距離了解。
需要注意的是，拓展技術寬度並不意味著僅僅只是知道一個技術名詞，而是要深入去理解每個技術的原理、優缺點、應用場景，否則就會成為傳說中的“PPT 技術專家”。例如，以 Java 開發為例，知道 Netty 是個高效能網路庫是遠遠不夠的，還需要學習 Netty 的原理，以及具體如何使用 Netty 來開發高效能系統。
初級架構師-階段描述
成長為初級架構師需要 5~10 年時間，其典型特徵就是能夠“獨立完成一個系統的架構設計 ”，可以是從 0 到 1 設計一個新系統，也可以是將架構從 1.0 重構到 2.0。初級架構師負責的系統複雜度相對來說不高，例如後臺管理系統、某個業務下的子系統、100 萬 PV 量級的網站等。
初級架構師和技術專家的典型區別是：架構師是基於完善的架構設計方法論的指導來進行架構設計，而技術專家更多的是基於經驗進行架構設計 。簡單來說，即使是同樣一個方案，初級架構師能夠清晰地闡述架構設計的理由和原因，而技術專家可能就是因為自己曾經這樣做過，或者看到別人這樣做過而選擇設計方案。
但在實踐工作中，技術專家和初級架構師的區別並不很明顯，事實上很多技術專家其實就承擔了初級架構師的角色，因為在系統複雜度相對不高的情況下，架構設計的難度不高，用不同的備選方案最終都能夠較好地完成系統設計。例如，設計一個日 PV 100 萬的網站，MySQL + Memcache + Spring Boot 可以很好地完成，MongoDB + Redis + Nginx + php-fpm 也可以很好地完成，備選方案設計和選擇並不太難，更多的是看團隊熟悉哪個技術。
成長指導
從技術專家成長為初級架構師，最主要的是形成自己的“架構設計方法論 ”，我的架構設計專欄其實就是講述完整的架構設計方法論，包括架構設計目的、架構設計原則、架構設計步驟、架構設計模式等，類似的架構設計方法論還有《恰如其分的軟體架構：風險驅動的設計方法》和《領域驅動設計》等。
要形成自己的架構設計方法論，主要的手段有：
系統學習架構設計方法論，包括訂閱專欄或者閱讀書籍等。
深入研究成熟開源系統的架構設計，這個手段在技術專家階段也會用到，但關注點不一樣，同樣是研究開源系統，技術專家階段聚焦於如何更好地應用開源專案；初級架構師階段聚焦於學習其架構設計原理和思想，例如 Kafka 的文件中就有關於訊息佇列架構設計的分析和取捨。
結合架構設計方法論，分析和總結自己團隊甚至公司的各種系統的架構設計優缺點，嘗試思考架構重構方案。如果在這個基礎上真的能夠推動架構重構，那就更好了，既能夠實踐自己的架構設計方法論，同時積累經驗，又能夠展現自己的技術實力，拿到結果。
中級架構師-階段描述
成長為中級架構師需要 8 年以上時間，其典型特徵是“能夠完成複雜系統的架構設計 ”，包含高效能、高可用、可擴充套件、海量儲存等複雜系統，例如設計一個和 Kafka 效能匹敵的訊息佇列系統、將業務改造為異地多活、設計一個總共 100 人蔘與開發的業務系統等。
中級架構師與初級架構師的典型區別在於系統複雜度的不同，中級架構師面對的系統複雜度要高於初級架構師。以開源專案為例，初級架構師可能引入某個開源專案就可以完成架構設計，而中級架構師可能發現其實沒有哪個開源專案是合適的，而需要自己開發一個全新的專案，事實上很多開源專案就是這樣誕生出來的。
成長指導
從初級架構師成長為中級架構師，最關鍵的是“技術深度和技術理論的積累 ”，例如：
技術理論：CAP、BASE 是異地多活的設計理論基礎、Paxos 是分散式一致性的基礎演算法、2PC、3PC 是分散式事務的基礎演算法等。
技術深度：Kafka 用磁碟儲存還能做到高效是因為磁碟順序寫；Disruptor 高效能是結合 CPU 預讀取機制、快取行、無鎖設計等基礎技術；Storm 的高效異或確認機制；Flink 的分散式快照演算法等。
很多同學對這點可能有疑問，這些技術理論和技術深度的事情不應該是高階工程師階段或者技術專家階段就應該積累的麼？為何到了中級架構師階段反而是成長的關鍵了呢？主要原因在於高階工程師或者技術專家階段即使去學習這些技術，實際上也比較難理解透徹，更加難以有機會去應用，更多的時候只是瞭解有這個技術點而已；而到了中級架構師階段，面對高複雜度的系統，很多時候就是幾個關鍵技術細節決定整個架構設計的成敗，或者某個設計方案理論上就是不可行的，如果不深刻理解理論和相關的關鍵技術點，很難設計優秀的架構。
以我做過的異地多活設計方案為例，之前很早我就知道 CAP 理論了，但也僅僅只是知道幾個概念而已。真正做異地多活的時候，開始的時候還是走了不少彎路，試圖做一個完美的異地多活系統，最終發現這其實是不可能的，某天突然頓悟：其實 CAP 理論已經明確指出來了這點，但最初學習 CAP 理論的時候，很難有這樣深刻的理解。
高階架構師-階段描述
成長為高階架構師需要 10 年以上時間，其典型特徵是“創造新的架構模式 ”，例如：
谷歌大資料論文，創造了分散式儲存架構、分散式計算 MapReduce 架構、列式儲存架構，開創了大資料時代。
在有 MapReduce 分散式計算架構的背景下，Storm 又創造了流式計算架構。
在虛擬機器很成熟的背景下，Docker 創造了容器化的技術潮流。
高階架構師與中級架構師相比，典型區別在於“創造性”，高階架構師能夠創造新的架構模式，開創新的技術潮流。
成長指導
坦白的說，對於從中級架構師如何才能成長為高階架構師，我並沒有太好的指導，一個原因是我自我評價目前頂多算箇中級架構師；另外一個原因是一旦涉及“創造性”，其實和藝術就比較類似了，創造性實際上是很難學會的，也很難由老師教會，更多是天分，或者某種場景下靈感爆發。
參考技術界幾個創造性的架構案例，我總結出幾個可能誕生創造性架構的背景條件：
足夠複雜的業務場景：例如谷歌的大資料、阿里的雙十一、Facebook 的海量使用者等，業務場景越複雜，給技術帶來的挑戰更大，更有可能產生創造性的技術突破。
足夠強大的技術團隊：絕大部分創造性的架構都來源於大公司，或者知名的研究機構；沒有技術實力支撐，想突破也是心有餘而力不足。
不滿足於現狀的態度：例如虛擬機器很成熟但是資源佔用太多，所以發明 Docker；MapReduce 難以做到實時運算，所以創造 Storm 流式運算。
尊重技術價值的文化：創造性的東西往往需要投入大量的人力和時間，而且剛開始一般都不會很成熟，如果完全結果導向、KPI 導向，創新技術很可能在萌芽階段就被否定。
總結
關於如何在專業領域內提升，有條著名的“10000 小時定律”，簡單來說要成為某個領域頂尖的專業人才，需要持續不斷 10000 小時的練習，例如小提琴、足球、國際象棋、圍棋等領域，無一例外都遵循這個定律。我認為技術人員成長也基本遵循這個定律，我在文章中試圖提煉一條通用的成長路徑供你參考，但其實最關鍵的還是技術人員對技術的熱情以及持續不斷地投入，包括學習、實踐、思考、總結等。
最後，你可以統計一下自己從頭到尾認真讀過的技術書籍數量、系統研究過的開源專案的數量，然後自我評估一下自己目前處於哪個層級，看看是否有什麼發現？
“我自己是一名老程式設計師，辭職後在線上做講師，今年我整理了一份適合2019年學習的Java程式設計資料乾貨，從最基礎的面向物件到各種框架都有整理，送給每一位初學和進階中學習Java程式設計的小夥伴。"
加QQ群：730379855（招募中）