從淘汰邊緣到阿裡資深前端技術專家，他總結了 8 點

大家好，我在阿裡的花名叫梓骞，現在負責業務平台的體驗技術部，主營業務是阿裡業務中台體系的多端解決方案，同時還負責集團前端幾個基礎設施：Fusion、ARMS/Retcode前端監控、BizCharts資料可視化圖表方案、Node鏡像和部分Node中間件等。

跟大家分享我過往的經曆：

如這個路線圖中所呈現的，我其實并不是一開始就做前端，用現在的話說屬于全棧。工作之後從事過.Net開發和C++，其中C++可以算是有5、6年的開發經驗，隻不過整個過程都伴随業務前端的開發，直到在2012年因為業務需求專職從事前端開發工作。在整個過程中，有非常多的經曆，成長其實也是伴随整個過程一點一滴的積累，仔細回憶下，可以分成幾個階段。這幾個階段，也有一些對我發展起到決定性作用或者轉折的事情。

熱情

2003年~2007年，我在大連讀大學，加入了一個計算機社團，維護學校校園網以及另一個校園網站，雖然在之前就接觸過HTML開發，做過一個個人首頁(當時個人首頁很流行，而且名字基本都叫××的家)，但在社團裡是第一次接觸到動态網頁，才知道網站居然還有管理背景，之前以為是一個頁面一個頁面地複制出來的，也是至此就迷上web開發，從校園網站的内容編輯做起，再慢慢自學ASP開發，大一結束後已經可以獨立負責一個站點的技術開發工作。

機緣巧合，大二剛開學的時候學校的實體實驗室準備做一個選課系統，在學長的鼓勵下我去接了這個項目開發，用了幾周的時間完完全全由一個人開發完畢，不久就投入到學校營運，還記得是每周二中午實驗室會開放下一周的實驗課程，因為資源有限，大家一起去搶課程，當時用ASP+Access (是的，确實是Access當資料庫) 在一台伺服器上撐住了過千的并發，雖然慢但服務沒垮，也沒出現超賣的問題。現在想來，這不就是秒殺活動嗎。這個項目做得還算成功，當時也通過這個項目認識了非常多的老師，這也直接促使後面承接了更多更大的項目，最重要的項目是交通部的一個内容釋出系統，也是一個人花了兩個月的時間完成，當時在社團的辦公室裡經常一個人寫代碼寫一通宵，那個時候年輕，也樂此不疲，也沒覺得累。

大學四年業餘生活也是在不斷的開發和各種實際項目中度的。大學畢業的時候粗略統計了 一下，各種項目加一起代碼量大概在10W行左右。也是由于這些實際項目經驗，在大四的時候找工作，面試官問的很多問題基本都是實際項目中遇到過的，是以也很順利拿到了國内一家著名網際網路公司的校招offer，也是我第一家服務的公司。

打破正常，積極溝通

畢業後直接去了第一家公司，在這家公司裡，大家叫我的昵稱「泡泡」。可能因為做了太多OA類系統的原因，也直接被配置設定到企業IT部，相當于阿裡現在的企業智能事業部，對于畢業生，主要工作也就是開發各種審批流程。

随着開發的流程越來越多逐漸發現一些規律，有些審批流的代碼幾乎一緻，隻需要修改部分類名和關鍵資訊即可。可能過去在大學開發許多項目的經曆，有一個習慣一直保持到現在，那就是最受不了來一個頁面做一個頁面，如果出現重複性的勞動，我一定會想辦法用工具、改進架構、自動化等手段讓機器去做。是以當發現許多代碼是重複的時候，就特别想改變重複性的coding工作，最開始是批量替換，後來找了個代碼自動生成的工具，随着對所負責的系統架構越來越熟悉，逐漸改項目架構，每天下了也是在研究項目架構并自己寫demo去驗證，到年底總算可以實作對相似流程簡單配置一下就可完成。

正當自己對結果很開心的時候，認為自己是打破正常，不僅能完成工作也能主動去改變現有研發模式，但人生中第一個考核就是「待改進」，相當于阿裡的3.25，當時百思不得其解，跟主管聊過之後才發現自己存在幾個嚴重的問題，比如目标隻是完成工作，不關心業務和使用者，也不關心使用者體驗，甚至一個表達用了多種互動形式；再比如，不關心業務品質，甚至bug直接線上修改，也出現過故障；最後，最嚴重的問題，遇到問題抱怨過多，比如抱怨自己依賴的元件有bug，抱怨基礎設施不穩定等等，抱怨為什麼方案總在變，一個詞概括就是「學生思維」，比較自我總是站在自己的角度去看問題。

這次績效，現在看也一直認為是一個轉折點，自那以後基本停止抱怨，能夠主動打開心扉去接受現狀，去跟其他人溝通把自己的想法跟其他交流，主動去提出自己的改進方案，緊接着的一次考核，居然是A，相當于3.5+或者3.75-。現在想來很慶幸當時遇到一位負責的主管，如果是說保護畢業生在績效上放過一馬，或許再過半年當思維方式定型就改不過來了。

「泡泡出品，必屬精品」

一年半以後自己轉崗到業務部門，主要是C++，是以當時也是徹底從.Net技術棧切換到C++。依然保持打破正常、積極溝通，在一線繁忙的業務中完成一個又一個的項目，在業務部門的一個優勢就是，可以告訴親朋好友：“這個功能是我做的”，是以也特别關注業務，關注使用者體驗，而且當時公司的研發流程是：在送出測試前需要轉體驗，就是請産品經理體驗一下研發人員開發的項目是否是自己想要的，功能是否有遺漏，體驗好不好之類。

直到有一天，發生了一件我認為對我影響深遠的事情。有一次照例轉體驗，不一會收到産品經理的回複，大概意思是，體驗非常棒，泡泡做的簡直可以打上「泡泡出品」這個品牌了。這句話，可能本是産品經理一句恭維的話，雖然産品經理經常恭維程式員，但說者無心聽者有意，這不就是我一直所期望的嗎，經我手的項目，就是品質過硬體驗好，泡泡這個名字就是品牌。

也自那以後，我的對自己的要求就是送出測試後0 bug，使用者體驗就是一級棒，使用者用起來感受就是“這就是我想要的”。為此，自己模拟各種使用環境自測每一行代碼和異常處理，處理好每一個互動細節，比如對于動畫延遲，不斷去測試延遲100毫秒、200毫秒、300毫秒、400毫秒等參數，最後發現300毫秒是最自然的效果，于是把全站的延遲都調整到300毫秒，已達到全站所有同一個互動表達有統一的表現。 持續的投入總會有結果，後來部門期望提升研發流程的耗時，節省測試時間，試行對于簡單功能或者開發品質高的同學可以免測釋出，而我就是第一批被準許為免測釋出的人，我開發的程式可以直接釋出上線不需要測試，因為确實在資料中顯示，我已經有很長時間沒有被發現bug。

當然，在這背後也付出不少，除了有心去要求自己，技能也需要一點一滴去積累，也沒啥捷徑，計算機是一門實踐的科學，就是多寫代碼。在我14年離開這家公司的時候，我的代碼貢獻量是排到小組前列，離開兩年之後還有人告訴我，我的名字還排在前列。

個人經驗到組織能力和産品能力

個人職業生涯另外一個轉折點是在2012年，在之前都是C++是前端同時做，到了2012，随着移動裝置的興起，視訊的播放從傳統的flash過渡到HTML5，并且越來越重視播放體驗和變現能力，是以業務的重心也開始向播放體驗、廣告等方面傾斜，于是我開始專職做前端，主要是從事以HTML5為核心的移動端視訊播放和廣告播放。

HTML5播放并不是簡單的使用video标簽就可以解決的，這裡面涉及到播放相容性、播放品質跟蹤、清晰度切換、防盜鍊、CDN、貼片廣告、播放後推薦等因素，遠不是各種教程裡寫的簡單設定個video标簽和src就可以解決的，是以也在實際項目中攻克了很多技術細節。

然而視訊是網際網路最基礎的需求之一，越來越多的業務也需要嵌入視訊，也需要去适配各種移動裝置，前來咨詢的人越來越多，我發現我有一半的時間都在幫各種業務解決播放器調用的問題，于是開始寫了一個移動播放的白皮書，說明如何實作移動端播放。雖然文檔能解決部分咨詢的問題，但依然會有各種新的問題來咨詢，後來想想，為什麼我不把這些調用過程封裝成一個JSSDK呢，把想法跟主管溝通後得到大力支援，就這樣每天下班回家利用業餘時間花了近1個月開發出了這個SDK，隻需要傳入簡單幾個參數就可以自動适配平台渲染出播放器，最初被公司新聞App引用，後來又被公司多個具有海量通路的App引用，直到我離職，這個SDK成為當時前端組最核心的工作之一，每天的調用量超過億次。

時隔多年再回首這段經曆，才知道無形中做了一件我們稱之為“個人經驗到産品能力”的事情，就是把自己在長期業務中積累的專家經驗，以産品化的思路變成一個技術産品，讓不具備對應經驗的人也能很低門檻的使用現成的能力，達到經驗的可複制，服務更多的業務。

2014年來到當時的阿裡巴巴共享業務事業部，也就是我現在所屬的業務平台事業部的前身，承載了阿裡經濟體電商核心，建構阿裡巴巴商業作業系統，雖然現在支撐了阿裡經濟體衆多的電商業務，但在當時接手了非常多的淘系業務，而且許多業務都是PC端，大量的頁面依賴的Ajax接口傳回結果才能正确渲染，然而我們并不知道接口的穩定性到底如何。做前端最尴尬的事情就在于，所有的錯誤都表現在前端，直覺的感受就是前端不給力，進而影響到業務和使用者。是以急需對接口穩定性做監測，過去個人是有這方面的經驗，但尋找了阿裡現存的體系都無法滿足訴求，于是主動聯合中間件團隊發起了早期第一版的retcode監控平台(也就是現在阿裡雲前端監控産品ARMS的前身），同時配合幾個新業務的上線，效果很明顯，直接發現了多起線上問題，業務方也很認可，直接幫我們推薦給了其他團隊，是以也逐漸開始有其他團隊的同學介入。

是以對于Retcode，當時我們也面臨一個選擇，就是到底隻小精力投入滿足自己需求即可，還是開放出來給其他業務團隊使用，因為我們當時根本就沒有這麼多人力和伺服器預算，而且量變到質變，所要處理的資料量越來越大的時候，要投入的技術方案也會發生根本變化，對系統自身的穩定性要求也更高。後來的事情大家都知道了，我們選擇了開放出來讓大家都接入。我們考慮的原因是：

1. 有業務想接入，說明這個需求是真實存在的，Retcode在使用者端根據真實體驗的資料監測方式大家也是認可的；
2. 既然需求存在，即使不開放出來，其他業務也會自己做，那麼算上重複投入的人力和機器成本，反而更浪費，而我們開放出來以後，形成規模效應成本反而更容易控制。 開放出來以後，其實以開始路也并不順，開始服務不穩定，容量經常不夠，資料不準确，丢資料，還需要解決權限控制等等，以及各個業務也會提出很多需求，功能也需要不斷完善，整個過程也是非常的煎熬，當時給團隊要求也是堅持一年，一定會有好的結果。一年之後，我們不僅打磨出了一款好的産品，還曆練出多位在前端APM領域的人才，在全國諸多技術分享大會上也見到了他們的身影。

到了2016年，我們的業務形态是大量的ToB、ToE系統的開發，要适配多個BU的設計風格，技術體系上也在React趨勢上行的階段，急需一套打通設計到前端實作的UI域研發體系。經過一系列的調研和合作溝通，跟ICBU前端團隊一起拍了合作的意向，并跟當時的國際UED的設計師一起孵化了Fusion體系。整個過程其實也是将多位設計師長期在項目中的設計分解經驗和多位前端技術抽象的經驗，通過技術産品化，把多位專家的優秀經驗，從組織能力更新成産品能力。Fusion的能力提升，也是随着Fusion支援的業務場景越來越多，逐漸将上層業務的需求和用法沉澱下來的，比如一開始是不具備國際化能力的，配置平台和文檔也是全中文，這是在支援lazada業務之後才開始具備國際化的能力；一開始也沒有資訊無障礙能力，也是因為适配國際業務的法務要求才沉澱下來，一開始對這塊也沒太多經驗，部分同學在業務中具備了個人經驗之後，再将經驗産品化。

主動補位，不給自己設限

因為過去的項目經曆，本身自己算是全棧經曆，是以一直認為前端不是因為我們用JavaScript，而是因為我們站在業務最前端，解決業務端的問題，是以我們是前端。這個思想一直作為我從事前端崗位做決策的依據之一，隻要認為是跟端相關，影響到使用者，那就是我們的職責，或者是我們要去推動解決的。越是開創新戰場的打仗團隊，其實職責越不清晰。

印象最深的就是在lazada Voyager項目中，因為是開辟一個新的戰場，時間緊任務重，許多人也是從其他團隊抽調臨時組建起來的，其實有挺多職責不确定的事情，沒有說這是你的職責也沒說這不是。遇到這類事情，判斷的唯一依據就是，這是不是通過端去影響使用者的，如果是，那就是自己的職責，那麼剩下的就是兵來将擋水來土掩，排除萬難解決問題就好，比如項目中出現過用戶端人力不夠的情況，那麼考慮到業務進度，主動補位可以先用Weex或者H5先頂上，再比如埋點也是一個灰色地帶，産品經理也很忙，那就直接主動拉着産品經理一起去梳理。表面看來，多做了一些事情短期沒有任何的回報，甚至還額外加了很多班，但利他是最大的占便宜，在項目釋出後整個團隊受到的評價都是很正向。

關于現在和未來，目前主要工作是：

阿裡電商作業系統前端解決方案；

設計中台體系建設 —— 服務阿裡幾千名設計師和幾千名前端的設計提效、促進協同的設計體系；

承擔在集團部分Node中間件、Node鏡像等開發維護工作；

前端大學 —— 阿裡經濟體前端委員會人才發展方向；

其實，這幾塊工作裡，隻有第一項是我的kPI目标，而其他的比如第二個設計中台，我個人覺得這是建設商業作業系統UI域解決方案必須要強合作的事情，也由于自己過往在國際UED，對設計師的痛點也相對了解，自己也相信解決幾千名設計師和幾千名前端的協同合作效率，改變UI域的研發模式，一定會給集團甚至業界帶來效率的飛躍，這也是自己長期所相信的相信，既然自己也覺得有價值，跟自己的主要KPI也有關聯，那就去做。而其餘的事情，其實基本不在自己的KPI裡，但也是那句「Not Me，Who」，自己覺得有價值，這個事情也是需要去做的，那就去做好了。也沒有給自己設定限制。

總結

興趣是最好的老師，做一件事情首先是自己要有熱情，如果隻是當成一份工作，内心就很難讓你全情投入；

認真做事能把事情做完，用心做事能把事情做好；

利他是最大的占便宜；

前端不是因為我們用JavaScript，而是因為我們站在業務最前端，解決業務端的問題，是以我們是前端；

計算機是一門實踐的科學，多動手是王道，知其然知其是以然；

協同是「兩個人」的事，但協同成功是「一個人」的事，想要最終結果是成功，必須放下界限，向對方多走一步。

除了自己，沒人能給你設限。

做自己認為對的事情，并堅持下來。

以上，是我從業前端這個崗位過往的經曆和感悟，感謝閱讀，共勉。