阿里妹導讀：思維方式直接決定了一個人在工作上的效能和產出。經驗是個人對過往項目的總結和處理方式優化。今天的文章來自于阿里工程師梓騫，從大學第一次接觸動態網頁到現在的資深前端技術專家，他分享了那些人生中的“大事”，讓我們看到他是如何一步步轉變思維方式，積累經驗，升級打怪。

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

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

?

??

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

熱情

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

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

大學四年業余生活也是在不斷的開發和各種實際項目中度的。大學畢業的時候粗略統計了 一下，各種項目加一起代碼量大概在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，而是因為我們站在業務最前端，解決業務端的問題，所以我們是前端;
• 計算機是一門實踐的科學，多動手是王道，知其然知其所以然;
• 協同是「兩個人」的事，但協同成功是「一個人」的事，想要最終結果是成功，必須放下界限，向對方多走一步。
• 除了自己，沒人能給你設限。
• 做自己認為對的事情，并堅持下來。

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