2018年12月20日，云棲社區3周歲生日。阿里巴巴常說“晴天修屋頂”，所以我們特別策劃了這個專輯——分享給開發者們20個阿里故事，50本書籍。第一位是林昊（畢玄）。

在這篇《程序員的成長路線》里，阿里基礎設施負責人畢玄結合自己的經歷跟大家講述了他在各個角色上成長的感受。在他的職業經歷中，在成長方面經歷了技術能力的成長、架構能力的成長，以及現在作為一個在修煉中的技術 Leader 的成長。其中技術能力和架構能力的成長是所有程序員都很需要的，值得所有正為職業發展而迷茫的技術同學細細品味。

技術能力成長

我大學讀的是生物系，缺少了專業的訓練，這個使得我在技術能力上其實欠缺的更多。回頭想想，在工作的前5年，更多的都是在拓寬技術面，剛畢業的時候只會 ASP，工作前兩年學會了 VB、Delphi這些神器，到工作的第三、四年比較專注的做了工作流領域。

技術能力的成長主要還是在 2007 年加入阿里以后，在加入阿里前，我是一個連日均訪問量 1萬 PV 都沒見過的人，到了阿里后，做的第一件事竟然就是寫 HSF，并且在客服的 CRM 系統上線，訪問量大概是每天上百萬的服務調用，無知者無畏，當時也就那么上線了，更神奇的是竟然沒出現什么問題，于是繼續把HSF上線到當時的交易中心，當時交易中心每天的服務調用量大概是億級，結果上線當天就回滾了，而且還不知道到底是什么原因，這次的回滾是對我觸動最大的一次（當然，觸動大也有可能是后面要是解決不了，就該從淘寶滾蛋了）。

回滾后開始仔細查問題，最后發現是當時 HSF 所使用的 jboss-remoting 默認的超時參數 60s 的問題，自從這個問題后，才明白要支撐好到了一定量級的系統，最重要的是對整個技術棧的精通，否則出問題都不知道該怎么解決或臨時查，于是才開始仔細學習 Java 的 BIO/NIO，Mina，反射，并發編程等，盡管這些東西很多在加入阿里前也看過一些書、資料學過，但到了這個時候才發現自己其實不怎么懂，那段時間密集的開始更細致的看書，翻看用到的 Mina、甚至是 Java 的各種 API 背后的源碼，是自己的 Java 技能提升最快的一段時間，在回滾的兩個月后，基于 Mina 完全重寫了 HSF，再次上線終于一切順利。

在那之后，隨著 HSF 應用的場景越來越多，以及加上后來自己在淘寶消防隊查比較多的問題，Java 方面的技能也得到了不少成長，而同時也發現了很多的 Java 問題還得對 JVM、操作系統層面有一定掌握才行，尤其是 JVM，于是當時和還在阿里的撒迦經常一起周末跑到公司來結對看 JVM 代碼，:)。在撒迦的幫助下對 JVM 的掌握終于也越來越好，那段時光會讓自己明白很多東西只有看了代碼，并且有相應的使用機會才能真正的掌握。

在 HSF 之后，去做 HBase，學習了很多在存儲方面的技能，這也是我之前完全不懂的領域，在HBase之后，開始做第一代容器產品 T4（寓意是第四代淘寶技術），進入徹底不懂的領域，虛擬化、Cgroup 等等都是那個時候才開始學習，但因為沒詳細研究過代碼，并自己去做改造，其實到今天也就是點皮毛而已。

對于程序員而言，技術能力的成長顯然是最重要的（程序員行當里最贊的一句就是：Talk is cheap, show me the code!），我自己其實很多都屬于被逼的成長，當然這樣通常反而也是最快的，很多同學會覺得自己沒碰到這樣的機會，所以成長就比較慢，我會非常建議的是可以嘗試自己去創造一些場景（當然，如果本來就是工作需要就更好了），來學相應的技術能力（例如學 Java 的通訊框架，可以嘗試自己基于 BIO/NIO 寫一個，然后對比 Mina/Netty 這些成熟的，看看為什么寫的不太一樣，又例如學 Java 的內存管理，可以嘗試自己寫程序去控制 GC 的行為，例如先來一次 ygc，再來兩次 fgc，再來 5 次 ygc，再來一次 fgc之類的，學的時候除了一些入門的書外，我非常建議去翻看源碼，最后你會發現所有的書都不如源碼），這樣才能真正的理解和學會，否則其實很容易忘。

架構能力成長

說起架構，在我剛工作的第三年負責工作流系統的時候也做過，但直到后來在阿里做 T4、異地多活，我才有了真正更強烈的感受，對架構師也有更深的一些理解。架構呢，我現在的理解基本是一個結構圖，當然有不同視角的結構，但這個圖里的部分呢是多個團隊來做的，甚至是跨多個專業的團隊。

在做 T4 的時候，由于 T4 涉及到了標準的一個 Java WebConsole，一堆的運維體系，容器技術等，這是一個至少要跨三個團隊的結構，無論是從研發視角還是部署視角都是如此，因此作為 T4 的架構師，怎么設計好整個的結構，各自的邊界、接口是我當時最大的感受，讓跨專業的多個團隊能更好的協作，在這個階段中最重要的要考慮的是怎么根據整個項目的優先級來調整每個部分，以及作為一個不是全懂的架構師怎么更好的確保結果，我自己的感受是 T4 讓我學會了從一個只做自己專業系統的架構師成長為了能做跨專業的系統的架構師。

在做異地多活的時候，感受就更加強烈，因為這個跨的專業數、整個參與的人數完全是上升到了一個非常大的程度，各個專業、系統的人都需要看整個架構才能知道自己應該做什么，扮演的角色，在做異地多活整個項目過程中，作為總的架構師，我自己感覺的是最重要的職責是怎么控制項目的風險，或者說作為架構師，你覺得一個項目中最重要的要掌控住的是，并且從架構上怎么設計這個部分，這也是后來我在問很多架構師時最喜歡問的問題，一份架構文檔不是說按照模板寫就可以（很多的架構設計文檔都是千篇一律，通常看到的都是什么都考慮，但從架構設計上并沒體現這些考慮的地方是怎么做的），而是要根據實際的項目/產品情況來突出重點，確保最重要的幾個問題是從架構設計上就去掌控的，尤其是跨多個專業團隊的大型項目，這種項目準確的說是大架構師帶著一堆的專業領域的架構師來做的，例如異地多活項目從架構設計上來說除了正常的結構、邊界以外，最重要的是數據正確性的設計，我自己最強的感受就是異地多活才讓我明白了一個大型系統的架構師是怎么樣的。

所以就我自己的感受而言，架構師對知識的寬要求非常廣，并且要能非常好的進行抽象，來做結構、邊界的設計，分析出當前階段系統的重點，并從架構層面做好設計來確保重點的實現，這個相對技術能力的成長而言我覺得更需要機會，但同樣在機會前需要有足夠的積累（例如寫一個系統的時候，是不是主動的去了解過上下游的系統設計，是不是了解過具體的部署結構，對相應的知識點有沒有簡單的了解等，我自己在做 T4 前，LVS、機房/網絡結構等完全搞不懂是怎么回事）。

技術Leader修煉

技術 Leader 我比較傾向于有前面兩步積累的同學，技術 Leader 非常重要的一點是對技術趨勢的感知和判斷能力，這其實是個非常綜合的能力，一到兩個領域的技術深度，大的架構能力，對技術歷程的理解、技術發展的思考能力，作為技術 Leader 是很需要的，然后是其他的一些作為 Leader 方面的比較綜合的一些能力（例如組織搭建、建設方面的能力等，不過這些能力呢通常對技術的人來說確實會欠缺的更多一些），這個我自己還在修煉和學習中，就不講太多了。

總結

總結來說呢，我認為程序員可發展的路線還是很多的，上面寫的這三條其實都是可發展的路線，沒有孰優孰劣，誰高一等之類的，興趣、個人優勢仍然是最重要的。

---

作為《OSGi原理與最佳實踐》和《分布式Java應用：基礎與實踐》的作者，畢玄推薦了他的書單給到我們：

《硅谷之謎》
《智能時代：大數據與智能革命重新定義未來》

?

原文鏈接
本文為云棲社區原創內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的云栖专辑| 阿里毕玄：程序员的成长路线的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。