在阿里，習慣尊稱畢玄老師為“畢大師”。他 2007 年加入阿里，一手打造了 HSF，十多年來更見證、參與了阿里在基礎技術上的演進與發展。

例如淘寶在 2007-2009 年的分布式應用架構升級、2013-2016 年的阿里電商異地多活架構升級等。但很少有人知道，他大學讀的是生物專業。

左手代碼右手詩，亦是生活亦是癡。今天，畢玄老師將為你講述十多年開發經歷的收獲與感悟，希望能對你有所啟發。

從業余程序員到職業程序員

程序員剛入行時，我覺得最重要的是把自己培養成職業的程序員，我的程序員起步比同齡人都晚了很多，更不用說現在的年輕人了。

我大學讀的是生物專業，在上大學前基本算是完全沒接觸過計算機，軍訓的時候因為很無聊，我和室友每天跑去學校的機房玩。

我現在還印象很深刻，我***次走進機房的時候，別人問，你是要玩 Windows，還是 Dos，我那是完全的一抹黑。

后來就只記得在機房一堆人都是在練習盲打，軍訓完，盲打倒是練的差不多了，對計算機就這么產生了濃厚的興趣，大一的時候都是玩組裝機，搗鼓了一些，對計算機的硬件有了那么一些了解。

到大二后，買了一些書開始學習當時最火的網頁三劍客，學會了手寫 HTML、PS 的基本玩法之類的，課余、暑假也能開始給人做做網站什么的(ps: 那個時候做網站真的好賺錢)。

可能那樣過了個一年左右，做靜態的網頁就不好賺錢了，也不好找實習工作，于是就開始學 ASP，寫些簡單的 CRUD，做做留言板、論壇這些動態程序，應該算是在這個階段接觸編程了。

畢業后加入了深圳的一家做政府行業軟件的公司，一個非常靠譜和給我空間的 Leader，使得自己在那幾年有了不錯的成長，終于成了一個職業的程序員。

通常來說，業余或半職業的程序員，多數是 1 個人，或者很小的一個團隊一起開發，使得在開發流程、協作工具（例如 jira、cvs/svn/git 等）、測試上通常會有很大的欠缺，而職業的程序員在這方面則會專業很多。

另外，通常，職業的程序員做的系統都要運行較長的時間，所以在可維護性上會特別注意，這點我是在加入阿里后理解更深的，一個運行 10 年的系統，和一個寫來玩玩的系統顯然是有非常大差別的。

這塊自己感覺也很難講清楚，只能說模模糊糊有個這樣的概念，通常在有興趣的基礎上，從業余程序員跨越到成為職業程序員我覺得不會太難。

編程能力的成長

作為程序員，最重要的能力始終是編程能力，就我自己的感受而言，我覺得編程能力的成長主要有這么幾個部分。

編程能力初級：會用

編程，首先都是從學習編程語言的基本知識學起的，不論是什么編程語言，有很多共同的基本知識。

例如怎么寫***個 Hello World、if/while/for、變量等，因此我比較建議在剛剛開始學一門編程語言的時候，還是就看看編程語言自己的一些文檔就好，而不要上來就去看一些高階的書。

我當年學 Java 的時候上來就看 Think in Java、Effective Java 之類的，真心好難懂。

除了看文檔以外，編程是個超級實踐的活，所以一定要多寫代碼，只有這樣才能真正熟練起來，這也是為什么我還是覺得在面試的時候讓面試者手寫代碼很重要。

這個過程是非常容易判斷寫代碼的熟悉程度的，很多人會說由于寫代碼都是高度依賴 IDE 的，導致手寫很難，但我絕對相信寫代碼寫了很多的人，手寫一段不是太復雜的可運行的代碼是不難的。

即使像我這種三年多沒寫過代碼的人，讓我現在手寫一段不太復雜的可運行的 Java 程序，還是沒問題的，前面 N 年的寫代碼生涯使得很多東西已經深入骨髓了。

我覺得編程能力初級這個階段對于大部分程序員來說都不會是問題，勤學苦練，是這個階段的核心。

[[257367]]

編程能力中級：會查和避免問題

除了初級要掌握的會熟練的使用編程語言去解決問題外，中級我覺得首先是提升查問題的能力。

在寫代碼的過程中，出問題是非常正常的，怎么去有效且高效的排查問題，是程序員群體中通常能感受到的大家在編程能力上***的差距，解決問題能力強的基本很容易在程序員群體里得到很高的認可。

在查問題的能力上，首先要掌握的是一些基本的調試技巧，好用的調試工具，就像在 Java 里 JDK 自帶的 jstat、jmap、jinfo，不在 JDK 里的 mat、gperf、btrace 等。

工欲善其事必先利其器，在查問題上是非常典型的，有些時候大家在查問題時的能力差距，有可能僅僅是因為別人比你多知道一個工具而已。

除了調試技巧和工具外，查問題的更高境界會和編程能力的高級階段有非常大的關系，就是懂原理，一個懂原理的程序員在查問題的水平上是有明顯差距的。

我想很多的同學應該能感受到，有些時候查出問題的原因僅僅是因為有效的工具，知其然不知其所以然，我給很多阿里的同學培訓過 Java 排查問題的方法。

在這個培訓里，我經常也會講到查問題的能力的培養最主要的也是熟練，多嘗試給自己寫一些會出問題的程序，多積極的看別人是怎么查問題的，多積極的去參與排查問題，很多***查問題能力強的人多數僅僅是因為“無他，但手熟爾”。

就像我自己，排查問題能力的提升主要是在 2009 年和 2010 年，那兩年作為淘寶消防隊（處理各種問題和故障的虛擬團隊）的成員處理了很多的故障和問題。

當時消防隊還有阿里最公認的技術大神多隆，向他學習到了很多排查問題的技巧，和他比，我排查問題的能力就是初級的那種。我印象最深刻的是有一次我們一起查一個應用 cpu us 高的問題。

我們兩定位到是一段代碼在某種輸入參數的時候會造成 cpu us 高的原因后，我能想到的繼續查的方法是去生產環境抓輸入參數，然后再用參數來本地 debug 看是什么原因。

但多隆在看了一會那段代碼后，給了我一個輸入參數，我拿這個參數一運行，果然 cpu us 很高，哎，而且這種 case 不是一次兩次。

所以我經常和別人說，我是需要有問題場景才能排查出問題的，但多隆是完全有可能直接看代碼就能看出問題的，這是本質的差距。

[[257368]]

除了查問題外，更厲害的程序員是在寫代碼的過程就會很好的去避免問題，大家最容易理解的就是在寫代碼時處理各種異常情況。

但這里通常也是程序員們很大的差距的地方，寫一段正向邏輯的代碼，大部分情況下即使有差距，也不會太大，但在怎么很好的處理這個過程中有可能出現的異常上，這個時候的功力差距會非常明顯。

很多時候一段代碼里處理異常邏輯的部分都會超過正常邏輯的代碼量，我經常說，一個優秀程序員和普通程序員的差距，很多時候壓根就不需要看什么滿天飛的架構圖，而只用 show 一小段的代碼就可以。

舉一個小 case 大家感受下，當年有一個嚴重故障，***查出的原因是輸入的參數里有一個是數組，把這個數組里的值作為參數去查數據庫，結果前面輸入了一個很大的數組，導致從數據庫查了大量的數據，內存溢出了。

很多程序員現在看都會明白對入參、出參的保護 check，但類似這樣的 case 在我自己排查問題的經歷了真的碰到了好多。

在中級這個階段，我會推薦大家盡可能的多刻意的去培養下自己這兩個方面的能力，成為一個能寫出高質量代碼、有效排查問題的優秀程序員。

編程能力高級：懂高級 API 和原理

就我自己的經歷而言，我是在寫了多年的 Java 代碼后，才開始真正更細致的學習和掌握 Java 的一些更高級的 API。

我相信多數 Java 程序員也是如此，我算是從 2003 年開始用 Java 寫商業系統的代碼，但直到在 2007 年加入淘寶后，才開始非常認真的學習 Java 的 IO 通信、并發這些部分的 API。

盡管以前也學過也寫過一些這樣的代碼，但完全就是皮毛，當然，這些通常來說有很大部分的原因會是工作的相關性。

多數的寫業務系統的程序員可能基本就不需要用到這些，所以導致會很難懂這些相對高級一些的 API，但這些 API 對真正的理解一門編程語言我覺得至關重要。

在之前的程序員成長路線的文章里我也講到了這個部分，在沒有場景的情況下，只能靠自己去創造場景來學習好，我覺得只要有足夠的興趣，這個問題還是不大的。

畢竟現在有各種開源，這些是可以非常好的幫助自己創造機會學習的，例如學 Java NIO，可以自己基于 NIO 包一個框架，然后對比 Netty，看看哪些寫的是不如 Netty 的，這樣會非常有助于真正的理解。

在學習高級 API 的過程中，以及排查問題的過程中，我自己越來越明白懂編程語言的運行原理是非常重要的。

因此我到了后面的階段開始學習 Java 的編譯機制、內存管理、線程機制等，對于我這種非科班出身的而言，學這些會因為缺乏基礎更難很多。

但這些更原理性的東西學會了后，對自己的編程能力會有質的提升，包括以后學習其他編程語言的能力。

學這些原理***的方法我覺得是先看看一些講相關知識的書，然后去翻看源碼，這樣才能真正的更好的掌握，***是在以后寫代碼的過程中、查問題的過程中多結合掌握的原理，才能做到即使在 N 年后也不會忘。

在編程能力的成長上，我覺得沒什么捷徑，非常贊同 1 萬小時理論，在中級、高級階段如果有人指點或和優秀的程序員們共事，會好非常多。

不過我覺得這個和讀書也有點像，到了一定階段后（例如高中），天分會成為最重要的分水嶺，不過就和大部分行業一樣，大部分的情況下都還沒到拼天分的時候，只需要拼勤奮就好。

系統設計能力的成長

除了少數程序員會進入專深的領域，例如 Linux Kernel、JVM，其他多數的程序員除了編程能力的成長外，也會越來越需要在系統設計能力上成長。

通常一個編程能力不錯的程序員，在一定階段后就會開始承擔一個模塊的工作，進而承擔一個子系統、系統、跨多領域的更大系統等。

我自己在工作的第三年開始承擔一個流程引擎的設計和實現工作，算是一個不算小的系統，并且也是當時那個項目里的核心部分，那個階段學會了一些系統設計的基本知識。

例如需要想清楚整個系統的目標、模塊的劃分和職責、關鍵的對象設計等，而不是上來就開始寫代碼，但那個時候由于我是一個人寫整個系統，所以其實對設計的感覺并沒有那么強力的感覺。

在那之后的幾年也負責過一些系統，但總體感覺好像在系統設計上的成長沒那么多，直到在阿里的經歷，才敢說自己在系統設計上有了越來越多的體會（References 里有一篇我在系統設計上犯過的 14 個錯，可以看到我走的一堆的彎路）。

在阿里有一次做分享，講到我在系統設計能力方面的成長，主要是因為三段經歷：

• 負責專業領域系統的設計
• 負責跨專業領域的專業系統的設計
• 負責阿里電商系統架構級改造的設計

***段經歷：負責 HSF

HSF 是一個從 0 開始打造的系統，它主要是作為支撐服務化的框架，是個非常專業領域的系統，放在整個淘寶電商的大系統來看，其實它就是一個很小的子系統。

這段經歷里讓我最深刻的有三點：

①要設計好這種非常專業領域的系統，專業的知識深度是非常重要的

我在最早設計 HSF 的幾個框的時候，是沒有設計好服務消費者/提供者要怎么和現有框架結合的，在設計負載均衡這個部分也反復了幾次，這個主要是因為自己當時對這個領域掌握不深的原因造成的。

②太技術化

在 HSF 的階段，出于情懷，在有一個版本里投入了非常大的精力去引進 OSGi 以及去做動態化。

這個后來事實證明是個非常非常錯誤的決定，從這個點我才真正明白在設計系統時一定要想清楚目標，而目標很重要的是和公司發展階段結合。

③可持續性

作為一個要在生產環境持續運行很多年的系統而言，怎么樣讓其在未來更可持續的發展，這個對設計階段來說至關重要。

這里最 low 的例子是最早設計 HSF 協議的時候，協議頭里竟然沒有版本號，導致后來升級都特別復雜。

最典型的例子是 HSF 在早期缺乏了服務 Tracing 這方面的設計，導致后面發現了這個地方非常重要后，全部落地花了長達幾年的時間。

又例如 HSF 早期缺乏 Filter Chain 的設計，導致很多擴展、定制化做起來非常不方便。

第二段經歷：做 T4

T4 是基于 LXC 的阿里的容器，它和 HSF 的不同是，它其實是一個跨多領域的系統，包括了單機上的容器引擎，容器管理系統，容器管理系統對外提供 API，其他系統或用戶通過這個來管理容器。

這個系統發展過程也是各種犯錯，犯錯的主要原因也是因為領域掌握不深，在做 T4 的日子里，學到的最重要的是怎么去設計這種跨多個專業領域的系統，怎么更好的劃分模塊的職責，設計交互邏輯。

這段經歷對我自己更為重要的意義是我有了做更大一些系統的架構的信心。

[[257369]]

第三段經歷：做阿里電商的異地多活

這對我來說是真正的去做一個巨大系統的架構師，盡管我以前做 HSF 的時候參與了淘寶電商 2.0-3.0 的重大技術改造。

但參與和自己主導是有很大區別的，這個架構改造涉及到了阿里電商眾多不同專業領域的技術團隊。

在這個階段，我學會的最主要的：

①子系統職責劃分

在這種超大的技術方案中，很容易出現某些部分的職責重疊和沖突，這個時候怎么去劃分子系統，就非常重要了。作為大架構師，這個時候要從團隊的職責、團隊的可持續性上去選擇團隊。

②大架構師最主要的職責是控制系統風險

對于這種超大系統，一定是多個專業領域的架構師和大架構師共同設計，怎么確保在執行的過程中對于系統而言最重要的風險能夠被控制住，這是我真正的理解什么叫系統設計文檔里設計原則的部分。

設計原則我自己覺得就是用來確保各個子系統在設計時都會遵循和考慮的，一定不能是虛的東西。

例如在異地多活架構里，最重要的是如何控制數據風險，這個需要在原則里寫上，最基本的原則是可接受系統不可用，但也要保障數據一致。

而我看過更多的系統設計里設計原則只是寫寫的，或者千篇一律的，設計原則切實的體現了架構師對目標的理解（例如當時異地多活這個其實開始只是個概念，但做到什么程度才叫做到異地多活，這是需要解讀的，也要確保在技術層面的設計上是達到了目標的），技術方案層面上的選擇原則，并確保在細節的設計方案里有對于設計原則的承接以及執行。

③考慮問題的全面性

像異地多活這種大架構改造，涉及業務層面、各種基礎技術層面、基礎設施層面，對于執行節奏的決定要綜合考慮人力投入、機器成本、基礎設施布局訴求、穩定性控制等，這會比只是做一個小的系統的設計復雜非常多。

系統設計能力的成長，我自己覺得最重要的一是先在一兩個技術領域做到專業，然后盡量擴大自己的知識廣度。

例如除了自己的代碼部分外，還應該知道具體是怎么部署的，部署到哪去了，部署的環境具體是怎么樣的，和整個系統的關系是什么樣的。

像我自己，是在加入基礎設施團隊后才更加明白有些時候軟件上做的一個決策，會導致基礎設施上巨大的硬件、網絡或機房的投入。

但其實有可能只需要在軟件上做些調整就可以避免，做做研發、做做運維可能是比較好的把知識廣度擴大的方法。

第二點是練習自己做 tradeoff 的能力，這個比較難，做 tradeoff 這事需要綜合各種因素做選擇，但這也是所有的架構師最關鍵的，可以回頭反思下自己在做各種系統設計時做出的 tradeoff 是什么。

這個***是親身經歷，聽一些有經驗的架構師分享他們選擇背后的邏輯也會很有幫助，尤其是如果恰好你也在同樣的挑戰階段，光聽最終的架構結果其實大多數時候幫助有限。

技術 Leader 我覺得***是能在架構師的基礎上，后續注重成長的方面還是有挺大差別，就不在這篇里寫了，后面再專門來寫一篇。

[[257370]]

程序員金字塔

我認為程序員的價值關鍵體現在作品上，被打上作品標簽是一種很大的榮幸，作品影響程度的大小我覺得決定了金字塔的層次，所以我會這么去理解程序員的金字塔。

當然，要打造一款作品，僅有上面的兩點能力是不夠的，作品里很重要的一點是對業務、技術趨勢的判斷。希望作為程序員的大伙，都能有機會打造一款***的作品，去為技術圈的發展做出貢獻。

由于目前 IT 技術更新速度還是很快的，程序員這個行當是特別需要學習能力的，我一直認為，只有對程序員這個職業真正的充滿興趣，保持自驅，才有可能在這個職業上做好，否則的話是很容易淘汰的。