阿里畢玄：從生物系學生，到技術團隊 leader，他是如何完成自我蛻變的

© MSuzanne D. Williams

編者按：

新的技術層數不窮，困擾程式設計師的不僅有學不完的新技術，還有每個人在職業生涯中必然會面對的成長路線問題。這就像一個產品有了清晰的roadmap，下一步走的才會更自信。本文整理自程式設計師畢玄的《程式設計師的成長路線（續）》，講述了自己加入阿里後的技術成長曆程。

本文首發於作者的個人公眾號“Hello Java”，更多關於程式設計師的成長故事，請點選公眾號底部選單“技術之外”。

技術能力成長

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

技術能力的成長主要是在07年加入阿里之後。在加入阿里前，我是一個連日均訪問量1w PV都沒見過的人，到了阿里，做的第一件事竟然是要寫HSF（阿里內部使用的RPC服務框架），並且要在客服的CRM系統上線，當時的訪問量大概是每天上百萬的服務呼叫，無知者無畏，然後就那麼上線了，神奇的是，竟然沒出現什麼問題。

於是繼續把HSF上線到交易中心，當時交易中心每天的服務呼叫量大概是1億左右，結果上線當天就回滾了，而且還不知道到底是什麼原因，這次的回滾是我做技術以來觸動最大的一次（觸動大是因為：如果要是解決不了，可能就要從淘寶滾蛋了）。回滾後開始仔細查問題，最後發現是當時HSF所使用的jboss-remoting預設的超時引數60s的問題，自從這個問題後，才明白：

“要支撐好到了一定量級的系統，最重要的是對整個技術棧的精通，否則出問題都不知道該怎麼解決或臨時查。”

© Matt Duncan

於是才開始仔細學習Java的BIO/NIO、Mina、反射和併發程式設計等，儘管這些東西在加入阿里前也看過一些書和資料，但到了用的時候才發現自己其實不怎麼懂。於是那段時間開始更密集、更細緻的看書，翻看用到的Mina、甚至是Java各種API背後的原始碼，那也是自己的Java技能提升最快的一段時間。在回滾的兩個月後，基於Mina完全重寫了HSF，再次上線時一切順利。

在那之後，隨著HSF應用的場景越來越多，以及在淘寶消防隊需要去查各類問題，Java方面的技能得以獲得了持續的提升。同時，我發現很多的Java問題要處理的好，還要對JVM、作業系統層面有一定的掌握才行，尤其是JVM。於是和當時還在阿里的撒迦，經常一起週末跑到公司結對看JVM程式碼，:)，在撒迦的幫助下，對JVM的掌握也越來越好，那段時光讓自己明白：

“只有看了程式碼，並且有相應的場景去使用，才有機會真正的掌握它。”

在HSF之後，去做HBase，學習到了儲存方面的很多技能，這也是我之前完全不懂的領域，在HBase之後，開始做T4，進入徹底不懂的領域，虛擬化、Cgroup等等都是那個時候才開始學習，但因為沒詳細研究過程式碼，而且只是去做改造的工作，所以到今天也只是懂點皮毛而已。

© Jake Hills

對於程式設計師而言，技術能力的成長顯然是最重要的（程式設計師行當裡最讚的一句就是：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這個專案，讓我有機會從一位只做某個專業系統的架構師成長為一位能做跨專業系統的架構師。

在做異地多活的時候，感受就更加強烈了。因為異地多活所涉及的技術領域、以及參與專案的人數規模都上升到了一個非常高的程度，來自各專業、各系統的人都需要在看了整個架構後，才能知道自己應該做什麼和扮演的團隊角色。

“在做異地多活的專案過程中，作為總架構師，最重要的職責是如何控制專案的風險，找出專案中的核心，並且從架構上去思考如何去設計這個部分。”

© Jonna konsinska

這也是我在和很多架構師交流時，最喜歡問的問題。一份架構文件不是說按照模板寫就可以（很多的架構設計文件都是千篇一律，通常看到的都是什麼都考慮，但從架構設計上並沒體現這些需要重點考慮的地方是怎麼做的），而是要根據實際的專案/產品情況來突出重點，確保最重要的幾個問題是從架構設計上就去掌控的，尤其是跨多個專業團隊的大型專案。這種專案準確的說，是大架構師帶著很多專業領域的架構師來一起來做的，例如，異地多活專案從架構設計上來說，除了正常的結構、邊界以外，最重要的是資料正確性的設計。異地多活架構師的這段經歷，在我架構能力的積累上起到了非常重要的作用。

“架構師對知識寬度的要求非常高，並且要能非常好的進行抽象，來做結構、邊界的設計，分析出當前階段系統的重點，並從架構層面做好設計來確保專案重點的實現。”

相對技術能力的成長而言，架構能力的成長更需要職業機會和場景。但在機會前，同樣需要有足夠的積累，例如在寫一個系統的時候，是不是主動的去了解過上下游的系統設計，是不是瞭解過具體的部署結構，對相應的知識點有沒有簡單的瞭解等。我在做T4前，LVS、機房/網路結構等完全搞不懂是怎麼回事。

技術Leader修煉

技術Leader需要有對技術趨勢的感知和判斷能力，這是非常綜合的能力。同時，具備一到兩個領域的技術深度，大的架構能力，以及對技術歷程的理解、技術發展的思考能力。然後是其他的一些比較綜合的能力，例如組織搭建、建設方面等。不過綜合能力這塊，對技術人來說，通常會欠缺的更多一些，這方面我也還在修煉和學習中，就不講太多了。

總結

總結來說，我覺得和在之前文章裡寫的一樣，程式設計師可發展的路線還是很多的，上面寫的這三條其實都是可發展的路線，沒有孰優孰劣，誰高一等之類的，興趣和個人優勢仍然是最重要的。

畢玄：阿里雲開發者中心負責人，阿里系統軟體、中介軟體、研發效能負責人。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31562044/viewspace-2375196/，如需轉載，請註明出處，否則將追究法律責任。