程序员职业发展路径图：从菜鸟工程师到高级架构师
http://www.sohu.com/a/249729952_355140
踽踽獨行上下求索總是痛苦，如果有良師益友陪伴點撥必能事半功倍。從新手碼農到高級架構師，要經過幾步？要多努力，才能成為為人倚重的技術專家？本文將為你帶來一張程序員發展路徑圖，但你需要知道的是，天下沒有普適的道理，具體問題還需具體分析，實踐才能出真知。
架構師的“內功”
《從 0 開始學架構》專欄已經全部更新完畢，我在專欄里給你講述了我的完整架構設計方法論，包括架構設計的概念、原則、步驟、技巧、模式等，這些內容是我融合多年來的學習、實踐、思考總結得出來的精華?！巴跗抛钥洹币幌?#xff0c;專欄就相當于一部《九陽真經》，你按照武功秘籍的方法去修煉，自然能夠比站在村口大樹下打木人樁效率要高得多。然而要成為高手，光知道招式還遠遠不夠，更重要的是內功和判斷，能夠一眼看出對手的弱點或者破綻，知道“什么時候用什么招式”“遇到什么對手用什么招式”更重要。
以架構設計原則的“合適原則”為例，專欄講述了架構設計要遵循“合適原則”，不要過度設計，這個點非常關鍵，能夠避免架構設計的時候盲目超前設計。但是我們在具體架構設計的時候，到底什么是“合適”，專欄也無法給出一個明確的標準可以放之四海而皆準去套用，因為“合適”和很多因素有關：業務發展、團隊規模、技術實力、領導的喜好等。此時到底什么是“合適”就依賴架構師的“內功”了，很有可能同一個團隊，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 小時的練習，例如小提琴、足球、國際象棋、圍棋等領域，無一例外都遵循這個定律。我認為技術人員成長也基本遵循這個定律，我在文章中試圖提煉一條通用的成長路徑供你參考，但其實最關鍵的還是技術人員對技術的熱情以及持續不斷地投入，包括學習、實踐、思考、總結等。
最后，你可以統計一下自己從頭到尾認真讀過的技術書籍數量、系統研究過的開源項目的數量，然后自我評估一下自己目前處于哪個層級，看看是否有什么發現？
轉載于:https://www.cnblogs.com/davidwang456/articles/9585931.html
總結
以上是生活随笔為你收集整理的程序员职业发展路径图：从菜鸟工程师到高级架构师的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Docker源码分析（五）：Docker
- 下一篇： 1.25亿用户以后，Netflix总结的