今年的程式設計師節，也恰恰是我在阿里工作滿3年的時候，藉此機會盤點一下自己近3年來的工作，也為自己後續發展把把關。個人的眼界和思考總是有限的，特別是對於研究和技術領域來說，知道得越多，其實就會知道自己有多無知，從而對未知心生敬畏，並因未知的廣闊而興奮。
我是1976年生人，屬龍，今年41歲，所以可以算是老程式設計師了，15年前我讀研的時候，就被一起創業的小夥伴稱為老何了。我對寫程式碼確實喜歡，大概在96年，大三的時候拿到了高階程式設計師證書，算是一樁可以拿來吹的事。
博士畢業工作以來，最大的樂趣就是學習和深入思考。所以，從來不以工作過程中專案或者業務的簡單或者複雜而困惑。對自身的發展，我一直有一個明確的指導方針：一步一個腳印，提升自己解決問題的能力，不給自己設限。我大概在10年前面試一個40歲的大叔的時候，就認真地思考過，結論是：我喜歡寫程式碼，我會為此堅持一輩子。
一、既然這個專案這麼重要，我們就幹吧
迴歸正題，總結一下在阿里最近3年的工作。前兩年，我主要在御膳房資料引擎團隊做豬頭小隊長，聊兩個重點經歷的專案。
第一個就是5k+，一個通用大資料平臺。剛去一個月就趕上這個集合京杭兩地的大專案，確實蠻幸運的。在這個專案中印象深刻的有幾個地方吧，一個是立項的時候參與方案的討論，因為涉及京杭兩地、跨部門、跨團隊的溝通，各個團隊的老大難免在一起相愛相殺，我們一幫小弟在旁邊參與討論。一直相殺到凌晨的時候，在自由發言的階段，我實在忍不住，跳出來說：既然這個專案這麼重要，我覺得我們就幹吧。真的是仗著自己在創業公司積累的銳氣跳出來說這一句。我覺得大不了就是拼啦。
我說完就意識到這可能給自己的老大帶來了巨大的麻煩。很幸運我老大也早就扯煩了，站出來承擔責任，一時間各個老大分別出人出槍，一時間群情激奮。最後的責權分配在20分鐘內就完成了，甚至一位老阿里都哭了。
感謝那一晚上的感覺，也感謝阿里給我一幫很棒的隊友和老大。永遠記得，後面996兩個月，在京杭兩地互換出差的過程中，我負責兩個小模組的專案管理，我發揮自己解決問題快的能力，哪裡有窟窿我就去哪裡堵，當然，整個團隊的人都非常強大也非常努力。在最後專案結束評獎的時候，我拿了個最佳救火隊員獎，我真喜歡這個獎。
雖然我也是專案的PMO之一，但是除了打醬油，更多的是觀摩和學習阿里的專案管理和組織協調。這個專案真的很難，做的過程中經歷了各種妥協，專案完工後我們又斷斷續續還了一年的技術債，但是當時那種拼搏自己和燃燒自己成就BIG ONE的感覺，再難重現。後來也跟一些其他公司的同學溝通關於資料平臺構建的事情，發現我們真的走得很遠。因為是寫自己的感受，就不表揚其他同學了，要不然寫一本書都可以啦。
二、這不是我一個人的工作，只是努力使它變得完美
第二個專案也帶有我自己的強烈特色，我們一直被業務壓得很緊。但是對於引擎層研發來說，團隊成員也有自己的訴求，而且，系統要逐步完善和改進。在5K+專案完成後，我們依賴的一個重要模組開始頻繁出現問題，隨著團隊間溝通的深入，我們發現對方團隊的不穩定和發展方向不確定導致這個模組未來風險非常高。
我們首先想到的是部署一套新的作為過渡。在過渡階段，為了完成業務的同時來做這件事，我把團隊兩位同學的一部分業務工作承接過來，騰出人力開始做這件事。兩位同學遠赴杭州，出差一個月，把平臺基本接過來，保障了我們業務的平穩執行。
隨後，我們調研後果斷拋棄了這個模組的原有實現，調集團隊的技術力量重新規劃設計新的模組，除了替換，更重要的是為了發展。這一步走出後發現後面很多東西都活了，資料服務開始作為一個重要的點慢慢從整個平臺浮現出來，與資料團隊產生更深度的互動，進而隨著原資料服務的不穩定，催生了新的資料服務平臺。
這不是我一個人的工作，我只是努力使它變得完美。當初萬分糾結，每一步都步步驚心，現在相信每個參與這個專案的同學，心裡都是美好的回憶。而且，我們不僅通過這個專案成就了自己，更成就了兄弟團隊，成就了御膳房的發展。說大了。
三、技術挑戰是獵物，是機會，是戰功
在這三年裡，我不認為自己遇到了很大的技術挑戰，很多事情提前想到，組織技術專家提前討論，當和團隊在一起的時候，技術挑戰是獵物，是機會，是戰功。
舉一個簡單的例子來說明我做一個專案的過程，例如：我們要實現一個限流的服務，就是允許一個租戶的QPS最高多少。首先需要界定問題的邊界，包括：要不要考慮網路層攻擊(可能被其他模組處理掉)、未來一段時間業務的規模，系統穩定性、架構擴充套件性等。
這些問題確定後，會有一系列的技術方案成為技術選型，那麼如何判斷採用什麼技術方案，當時不是最新最酷的最好的，要考慮將來部署環境，上下游環境。最重要的這是一個分散式需求。簡單來說，N臺伺服器共同維護一個QPS值，這後面的分散式理論，樸素來說就是CAP，在CAP三者不能同時滿足的情況下，應該降低那個並保證業務的目標。
為此，我們參考分散式的BASE模型，降低了一致性的需求，採用分割槽和主體配額池結合的思路解決了大租戶的流量控制，而針對長尾租戶採用了另一套控制來保證精確限流。
同時考慮第三方模組和非關鍵模組掛掉或者降級中的應急預案，以及模組部分當機或者機房斷電導致的服務不可用，以及某些服務的單點問題等而設計完整的穩定性方案。當然，最後還要考慮擴充套件性方案，如果需求規模突然變大，但是整體是有邊界的。
總結起來，整個專案要有明確的目標和階段以及對應的關鍵指標，做到可觀測、可評估、可擴充套件、可恢復、以及容易交付給其他人繼續研發和維護。
我不認為自己做得很好，但是當逐步完善一個系統時，真的蠻快樂的。
四、我不認為做到35歲轉管理是必要的
現在細想起來，在我的成長道路上，給我提供技術指導的大牛真的很少，更多的時候，我更喜歡向任何一個我遇到的人學習，我學習的目的不是超越別人，而是超越自己。
轉崗到iDST團隊後，我坐在iDST老大的旁邊，有幸耳濡目染研發和管理達人的工作，受益匪淺。我一直覺得，程式設計師沒有人能教會，要的是自己的鑽研和用心的學習。包括我原來御膳房團隊的同學和現在iDST的同學，在合作和交流中，總能發現那些令你眼前一亮的優點和閃光點，這如何不欣喜？
另外，我覺得保持持續的思考和以開放的態度與其他同學溝通非常重要，互通有無。我覺得我目前最大的技術優勢可能還是在工程領域，主要是伺服器後端研發以及資料平臺建設這邊，主要是思考和經驗比較多。我會在理論和實踐兩個方面繼續增強自己的能力。與此同時，我一直在儲備自己在人工智慧方面的知識。得益於我博士論文期間在資訊檢索方向的深入思考，我很早就發現了這個能讓我著迷的領域。
這裡稍微聊兩句人工智慧領域，雖然一些人說這裡面也就是所謂的調參、特徵工程、訓練深度網路等。這些真的是門外漢才會這麼說。真正裡面需要的是理性的思維，解決這種沒有明確的路徑可尋的問題需要非常深入的思考、嘗試，經歷無數次失敗可能有一點小收穫，然後還要把這種小收穫用最精準的數學語言闡述出來，為後續的研發鋪平道路。
目前我剛剛讀完NLP領域的一本綜述——《統計自然語言處理》，正在重新構建自己的概率論和統計學的知識體系，儘量做到基本的概念信手拈來，然後找一個小的領域進行深入的思考和嘗試。對於我來說，找一個點建立一個模型，改改引數出一篇論文的誘惑不大，我希望能夠研究前人的研究成果，在理論深度有一定的突破。
在這個領域，那些談35歲就轉管理的程式設計師可能根本就無法明白。當遇到一個可以持續投入精力去鑽研，並且越鑽研覺得越難的事情的時候，對於我來說，何其幸運。更何況，我不認為做到35歲轉管理是必要的。管理並不好做，很多人以為管理就是分配工作，技術人員都是心高氣傲之輩，能力低的根本領導不了，只能領導能力更低的。而且真正的管理和寫程式碼一樣，也是一門學問，一門理論與實踐相結合，需要邊探索邊實踐的學問。人家讓你領導，是把自己的發展託付到你的手裡，所以是更重的責任。
from 朋友虞老闆拍攝，當我們吟誦春風不度玉門關的時候，玉門關其實是這個小土坑了。所以要辯證思考那些流傳的話，比如35歲前必須轉管理。
我主要利用上下班路上的時間來做機器學習的鑽研，每天大概3個鐘頭左右，上班時間主要還是寫業務程式碼，我熱愛寫碼，調通一個功能的感覺真爽！
舉個例子，《統計自然語言處理》，我用了將近一年的時間，在上班路上讀完，在讀到機器翻譯模型的時候，深深的迷醉於那5個IBM工程師發明的模型。這些模型發明的過程，思考的過程，是我學習的物件。
最後想說的是，在阿里，一樣經歷繁華，經歷迷茫，經歷失落甚至冷落，最重要的是守住自己的技術之心，與大家共勉。