阿里畢玄：程式設計師應如何選擇職業成長路線？

作者：畢玄

阿里雲開發者中心負責人

阿里系統軟體、中介軟體、研發效能負責人

阿里系統軟體、中介軟體、研發效能負責人畢玄結合自己的經歷跟大家講述了他在各個角色上成長的感受。在他的職業發展中，他經歷了技術能力的成長、架構能力的成長，以及現在作為一個在修煉中的技術 Leader 的成長。其中技術能力和架構能力的成長是所有程式設計師都很需要的，值得所有正為職業發展而迷茫的技術同學細細品味。

技術能力地成長主要還是在 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、機房/網路結構等完全搞不懂是怎麼回事）。

作為《OSGi 原理與最佳實踐》和《分散式 Java 應用：基礎與實踐》的作者，畢玄為成長中的程式設計師推薦了他的書單：

《矽谷之謎》
《智慧時代：大資料與智慧革命重新定義未來》