阿里畢玄：程序員應如何選擇職業成長路線？

時間 2019-11-06

原文原文鏈接

做者：畢玄 阿里雲開發者中心負責人 阿里系統軟件、中間件、研發效能負責人程序員

阿里系統軟件、中間件、研發效能負責人畢玄結合本身的經歷跟你們講述了他在各個角色上成長的感覺。在他的職業發展中，他經歷了技術能力的成長、架構能力的成長，以及如今做爲一個在修煉中的技術 Leader 的成長。其中技術能力和架構能力的成長是全部程序員都很須要的，值得全部正爲職業發展而迷茫的技術同窗細細品味。編程

技術能力成長

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

技術能力的成長主要仍是在 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之類的，學的時候除了一些入門的書外，我很是建議去翻看源碼，最後你會發現全部的書都不如源碼），這樣才能真正的理解和學會，不然其實很容易忘。分佈式

架構能力成長

提及架構，在我剛工做的第三年負責工做流系統的時候也作過，但直到後來在阿里作 T四、異地多活，我纔有了真正更強烈的感覺，對架構師也有更深的一些理解。架構呢，我如今的理解基本是一個結構圖，固然有不一樣視角的結構，但這個圖裏的部分呢是多個團隊來作的，甚至是跨多個專業的團隊。學習

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

在作異地多活的時候，感覺就更增強烈，由於這個跨的專業數、整個參與的人數徹底是上升到了一個很是大的程度，各個專業、系統的人都須要看整個架構才能知道本身應該作什麼，扮演的角色，在作異地多活整個項目過程當中，做爲總的架構師，我本身感受的是最重要的職責是怎麼控制項目的風險，或者說做爲架構師，你以爲一個項目中最重要的要掌控住的是，而且從架構上怎麼設計這個部分，這也是後來我在問不少架構師時最喜歡問的問題，一份架構文檔不是說按照模板寫就能夠（不少的架構設計文檔都是千篇一概，一般看到的都是什麼都考慮，但從架構設計上並沒體現這些考慮的地方是怎麼作的），而是要根據實際的項目/產品狀況來突出重點，確保最重要的幾個問題是從架構設計上就去掌控的，尤爲是跨多個專業團隊的大型項目，這種項目準確的說是大架構師帶着一堆的專業領域的架構師來作的，例如異地多活項目從架構設計上來講除了正常的結構、邊界之外，最重要的是數據正確性的設計，我本身最強的感覺就是異地多活才讓我明白了一個大型系統的架構師是怎麼樣的。

因此就我本身的感覺而言，架構師對知識的寬要求很是廣，而且要能很是好的進行抽象，來作結構、邊界的設計，分析出當前階段系統的重點，並從架構層面作好設計來確保重點的實現，這個相對技術能力的成長而言我以爲更須要機會，但一樣在機會前須要有足夠的積累（例如寫一個系統的時候，是否是主動的去了解過上下游的系統設計，是否是瞭解過具體的部署結構，對相應的知識點有沒有簡單的瞭解等，我本身在作 T4 前，LVS、機房/網絡結構等徹底搞不懂是怎麼回事）。

技術Leader修煉

技術 Leader 我比較傾向於有前面兩步積累的同窗，技術 Leader 很是重要的一點是對技術趨勢的感知和判斷能力，這實際上是個很是綜合的能力，一到兩個領域的技術深度，大的架構能力，對技術歷程的理解、技術發展的思考能力，做爲技術 Leader 是很須要的，而後是其餘的一些做爲 Leader 方面的比較綜合的一些能力（例如組織搭建、建設方面的能力等，不過這些能力呢一般對技術的人來講確實會欠缺的更多一些），這個我本身還在修煉和學習中，就不講太多了。