技術人生就是在不斷地修行，每個人都有每個人的功課，每個人也有每個人的精彩。你也許剛上路，又或許踽踽獨行了很久，聽聽別人的故事沒準也能幫助自己的成長。在阿里修行的9年，他學會了這些。

少年勵志，初入技術圈

我生在一個文化氣息濃厚的家庭，這讓我從小就對藝術有了一種懵懂的向往。第一次接觸到計算機時，我就明白自己會在這個領域玩下去；第一次接觸到互聯網時，我就堅定了將其作為事業，把自己的黃金年齡投入其中的信念。文化氣息的熏陶和堅定的信念，使得我踏上了尋找將美好的設計感和互聯網技術相結合的長路上。

2004年，我在上海畢業后，加入了COSCO。當時的環境有很好的應用場景和很牛的前輩，我在這個時期接觸到了一種可以被叫做前端的職業，接觸到了這個把「人的情感設計」和「技術的實現」連接在一起的令人興奮的事情，而這恰恰就是我當初最希望做的事情，于是毫不猶豫的將其作為自己立足的根本。除了找到自己的定位，我在這里收益最大的是快速學習并建立了自己的職場價值觀。

后來，我趕上了第二波互聯網浪潮。我不是那種希望很早就進入退休狀態的人，所以在2007年，我毅然決然地投身到 Web 2.0 的創業過程中。半年的時間，我們創業的產品就在當時的社區中具備了一定的知名度。這短短的半年時間，讓我在技術、設計、產品、用戶等方面都有了不錯的知識積累。

2008年，我們三個技術人的創業進入到了瓶頸期，我也明白了自己需要進一步學習的有哪些。此時，機緣巧合，我以一個普通的前端工程師的身份加入了阿里巴巴。

阿里九年，我所到達的四個站點

時光如梭，一晃眼，我加入阿里巴巴已快9年，這9年中，我經歷了4個重要的階段。

web前端全棧資料粉絲福利（面試題、視頻、資料筆記、進階路線）

第一站：UED團隊前端工程師

開始2年，我在UED團隊。作為一線的前端工程師，我參與了UED深度進入產品，強烈追求業務結果的發展時期。這為我深深地打下了用數據從用戶行為路徑的角度優化產品的思路。這使得我從進入前端正規軍的第一站開始，就有了一個需要站在比前端職責更大的角度去考慮如何工作的環境。這是我職業順利發展最為關鍵的因素。這個階段，我專注的領域在性能和體驗優化上。

第二站：UED團隊前端團隊Leader

2010年，由于所在UED團隊的調整，我成為了前端團隊的Leader。在此階段，我參加了AliExpress的初創團隊建設，又回歸到國際事業部。在負責了整個UED團隊管理一年后，我又回歸到前端團隊，同時也把前端團隊帶進了技術團隊。這個階段，讓我明白了前端這個角色的本心和這個階段所需要的環境，使得我心中的前端開始與技術團隊形成連線。

第三站：阿里巴巴企業事業群(B2B)的前端團隊Leader

2014年，隨著團隊的規模進一步擴大，我開始負責阿里巴巴企業事業群(B2B)的前端團隊，主要的職責是事業群下的前端團隊的整合和技術的收攏。這使得我必須在更大、更復雜的環境下，來看待前端團隊的定位。這個階段，讓我有機會思考企業架構下前端的價值和定位。

第四站：B類電商體驗技術中臺團隊Leader

2016年，在承接集團中臺建設的戰略后，我思考清楚并開始實踐研發中臺的建設，并略有成效。在中臺急切的落地的期待下，我加入到B類電商中臺團隊，進入到了當前的第四站，負責體驗技術中臺團隊。現在，我更多關注的課題是：如何在成熟的系統中去做收斂和統一，并為將來留下靈活性。當然，我依舊是從前端的角度切入。

我所經歷的B類電商平臺前端架構演進

我不敢妄言整個互聯網電商平臺的前端架構，因為沒有全部經歷過。但我在阿里巴巴B2B電商平臺的這段經歷，使得我有立場說一說B類電商平臺的前端架構演進。架構和業務的發展有密不可分的關系，下面我將結合業務發展階段對應的談前端架構在當下環境的特點和時間線上的演進。

「信息透出，促成雙方會面」階段

在電商平臺還在「信息透出，促成雙方會面」階段的時候，業務的主要特征是以 搜索 / 導購 作為主線，用戶鏈路以在線溝通意向為終點。業務模式很簡單，抽象起來就是用戶提供信息，電商平臺展示信息，協助買賣方在線溝通。在這個階段，前端的架構視角的關鍵詞是： 繼承式代碼復用，加載期性能治理。

繼承式代碼復用一般遵循著： 基礎框架 / 運行時; 組件基類; 基礎組件父類; 業務組件實例這樣的一個技術架構模型上。而在工程架構上的特點是： 覆蓋式發布 (含中美同步); 基本依賴管理; 性能治理 (壓縮，去重合并，監控)。

大家會發現，這個階段考慮的都是通用性問題。拋去電商的業務因素，可以發現這是個放之哪里都能用的架構，解決前端自身在研發過程中的問題占了絕對比重。

「在線交易達成」的階段

在電商平臺進入到「在線交易達成」的階段時，業務的主要特征就是：開始期望用戶把圍繞著交易的所有事務工作在線化；業務場景在之前的基礎上新納入各種復雜的用戶端信息管理(交易流程、糾紛流程、生意關系管理等)；用戶在平臺上需要完成的操作開始變得更多，使得人機交互場景變得更頻繁且有更高體驗要求。另外，多人協同研發的局勢也越來越明顯。在這個階段，前端的架構視角的關鍵詞是： 模塊化管理，前后端分層，執行期性能治理。

這個階段，應用場景出現了頻繁的數據交換需求，從而開始注重前后端的通信管理以及工作解耦，從而探索前后端的分層架構; 模塊化管理的進入引入了模塊管理器(離線/在線); 發布前構建，從而引入工程鏈的體系。因為開發環節的進一步復雜，對于質量治理，線上線下監控告警等都開始有意識的進一步完善。

大家還是會發現，該階段考慮的雖然還是屬于通用性問題，而解決的問題已經逐漸進入到大型復雜協同模式下需要面對的問題了，慢慢從框架之爭進入到了如何更好的組織代碼以及探索前端職責邊界。

電商平臺進入真正的平臺化階段

在電商平臺進入真正的平臺化，需要在目前的基礎上快速接入第三方服務(海關，稅務，銀行)，快速建設垂直市場(垂直行業市場，封閉市場，大企業采購市場等)，需要考慮的是如何解決大量不可預知的差異化的承接問題，這個問題已經需要站在整體企業架構中才能去嘗試解決的了。在這個階段，前端的架構視角的關鍵詞是：設計解構、邏輯調度、應用模型、分層標準化。

隨著業務的多樣性發展，整體架構的服務治理工作的開展以及人力緊張狀態的持續，我們需要進一步的去識別研發過程中能夠被進一步抽象和標準化的部分，并將變化的部分通過可配置、可編排的方式提供靈活的服務，并賦予業務實施的過程；需要進一步強化和明確在系統架構和信息架構間前端的轉化工作。

該階段考慮的部分逐漸破開前端的固有視角，開始從業務特征的視角，從數據消費者的視角，從用科學方法來解構專業的視角，來建設前端的能力。同時，也開始從前端自身的開發架構慢慢轉變到有一定業務特征的應用架構。

我看大型企業級架構前端分層

分層目的

分層的目的從根本上說有兩點：

解耦前后端開發工作

通過分層降低單層的復雜度

這兩點最終都能夠反應到效率上：一個效率點是瀑布式開發轉變成并行基于接口的開發，縮短開發任務路徑；另一個效率點是在面對業務調整時，降低復雜度的分層系統具備更強的靈活性，從而提升整個系統的響應效率。另外，分層對穩定性也有一定意義的幫助，基于層的測試能夠做的更加純粹和有針對性。同時，接口調用性能監控和全鏈路的性能監控在其中非常關鍵，用來做因為分層帶來的額外性能開銷可能存在風險的監控。

主流模型

主流的模型有兩種：

客戶端渲染 + 應用模型數據聚合

客戶端展現 + 服務端渲染 + 應用模型數據聚合

那么，應用模型數據聚合(為UI提供數據)和服務端渲染用什么實現呢？客戶端在承擔越來越多職責的情況下會進一步的引起思考，一些計算任務放置到服務端會更合適; 而業務領域模型的數據無法直接有效的對UI服務，需要有一層來處理數據消費者視角的數據加工工作。結合「同構」的意義，我們會發現JavaScript有了更大的應用場景。而我的觀點是JavaScript的運行時有了更大的應用場景，故不論是Node.js、Nashorn(甚至以前的Rhino)，亦或是直接使用V8都是可以做到我們想要做的事情，而讓JavaScript跑在服務端之外，整件事更應該關注的是穩定性，容災容錯，彈性，監控告警這些我們現在還有些陌生的領域。選型這件事不是語言偏好和角色之爭，而是系統應該做成什么狀態的思考。

分層通用原則

分層的通用原則有：

每一層完成獨立的功能，每層能夠獨立演進，獨立部署，獨立測試。

每一層的功能可依賴與處在同一層或下一層的功能，避免系統復雜度過高。

每一層功能的接口定義與接口實現要分離，對該層的訪問只能通過接口。

分層架構通過將事務處理的分層來分化系統的復雜性，提高系統的可擴展和可維護性。但同時因為分層事務處理導致需要在多個層間傳遞能力，會導致性能的損耗。目前談論的前端分層主要是集中在 presentation layer 和 business layer中的一部分。“每一層功能的接口定義與接口實現分離，對該層的訪問只能通過接口”，這個原則對前端的分層同樣有很強的指導意義，太多的不兼容底層框架升級導致業務實施有太多的額外成本開銷。這個恰恰是分層架構給我們前端在本職工作上需要的更多思考。

國際化站點的前端業務的特點

國際化站點的業務對于前端而言，最顯而易見的第一個問題是國際化部署; 然后是內容的國際化管理; 再往后是目前還在嘗試中的本地化。國際化部署對于前端而言不僅僅是把資源文件同步分發到全球各地機房就結束了的，源站和全球CDN中就有非常多的治理工作，比如CDN預熱、熱區規劃、緩存版本管理等; 而且資源文件和應用的發布在全球化發布過程中會被無限放大發布時間差的問題，應用的跨版本平滑發布，配置和文件冪等檢測等。

內容的國際化管理，首先是語種的國際化管理、用集中式鍵值對管理、熱部署、頁面內容識別等方法解決常用的應用中XML資源文件式的管理存在的管理困難，分散在應用中而帶來的冗余，發布困難，多語種應用定位等問題; 其次是類似 “單位 / 日期 / 貨幣 / 姓名格式” 等更精細化的國際化差異系統級管理。當然這里還有些挺特殊的例子，比如阿拉伯語、希伯來語的從右到左書寫方式。本地化(localization)區別于國際化(international)，更注重在本土文化的差異性上，目前還在探索。

我看大型企業中前端團隊的管理

關于團隊管理的問題，沒有正確答案。組織結構是在承接戰略而靈活變動的，而其中的優劣也是相對而言。作為管理者，需要解決的恰恰是享受了優勢之后隨之而來的問題，因為任何問題都會成對出現。例如，是否應當將前端的同學合攏在一個團隊呢？我們可以從專業建設、視角和組織靈活性來分析一下。

專業建設

合攏成一個團隊時，前端專業氛圍，對于前端個體而言，是一個較好的環境，但是在整體技術體系的建設上有一定局限性。

相反，分散到業務中，應用技術體系的專業建設，跨領域的知識儲備，一些組織問題帶來的隔閡會天然消失，對于業務開發者而言是一個較好的環境。但是專業發展可能會成為問題。

視角

合攏成一個團隊時，能夠將所有前端參與的業務信息集中在一起，能夠讓這個團隊(核心人員)有好的業務全局視角，但是對單個領域的了解和理解深度會有一定影響。

分散到業務中，對當前業務領域能夠有更為深入的了解和理解，能夠在特定領域中創新出特定的解決方案，但是缺乏更大緯度全局視角時會有一定的判斷限制（業務判斷和技術判斷）。

組織靈活性

合攏成一個團隊時，同一職能在不同業務中的組織靈活性強，能夠在業務的張弛中相互協調，但是容易被頻繁的資源協調工作占滿自己的日程。

分散到業務中，根據業務域進行專門的支撐，整體的目標感，溝通效率等跨職能的協同角度會更具優勢，但是職能角色的資源靈活性就會受限。

不論以哪種方式來組織前端的同學，都需要讓組織更加靈活，相應的關鍵因素有兩個：

前端在遵循統一的技術基礎之上一起建設支撐業務的統一基礎能力。

前端一致的角色價值認知。

這里統一的技術基礎和一致的角色價值認知，一實一虛，對應著技術的基礎和角色的文化：

統一的技術基礎，能夠讓一個組織中的前端在一個基礎上展開工作，也能夠讓前端的同學進入不同業務時，開發的基礎是一致的，也有討論技術時相對一致的談話基礎。統一的技術基礎可以讓業務領域的實施過程可以不過多關注底層技術實現，而更多的聚焦在業務解決方案的設計和實現上，可以不斷的沉淀出更有效的業務的基礎能力出來。

一致的角色價值認知是一個團隊一個角色統一的文化，比如在我的團隊，「鏈接商業，設計，計算能力，為用戶提供專業的人機交互體驗」。這是讓前端們能夠堅持前端的初心，而不會因為身處不同團隊，在做不同業務的工作時出現一些發展的迷茫。

前端群體發展方向：「云」和「端」。

「泛前端」或「大前端」的概念喊了很多年了，我認同這兩個詞，但有一些我自己的邏輯。前端當初出現的原因是「人機交互體驗」，用什么技術用什么語言去實現這個人機交互過程并不關鍵，但理念和目標應該是一致的，甚至在整個知識樹中，可能除了不同的端、不同語言、不同端交互的特征之外，基本知識結構上不會相差太多，甚至有差異性的地方還有很好的互相借鑒意義。

在企業中，前端的合作伙伴有非常多。理論上，作為前端個體而言，轉型成任何一種角色都挺正常。但對于一個群體而言，我認為在大緯度上會有兩種方向——「云」和「端」。

「端」容易理解，在各個端，利用各種技術，完成業務產品中的數據消費，信息架構，人機交互的工作(PC、無線、VR、AR等)。

「云」不是通常意義的云計算，而是借云計算和云開發者之間的關系類比一下，這里指「端」開發者在完成業務產品時所需要的基礎研發能力以及產品的能力的提供者。

前端工程師發展建議：思辨、容納和好奇心

我們的前端生態很活躍，這讓我的心理挺矛盾的。我一方面高興，是因為活躍的社區才能充滿創造力，而前端又極端的需要創造力。另一方面我又擔心，是因為在活躍的社區中，明天就有可能天翻地覆，誰都不知道我今天選擇的是不是代表未來，有那么點賭博的味道；而且頻繁的調整業務實現方式，困擾的不只是前端自己。

上文曾提到，我們通過分層架構，嘗試從技術上解決前端技術體系的頻繁變動而導致臨近技術體系需要被動調整的問題。除了技術上的應對，前端人或甚至說技術人想在這樣的環境中成長，應以什么樣的心態來應對呢？我有三個建議：思辨、容納和好奇心。

思辨

社區的活躍中，有語言的進步，有工具的進步。語言是你決定成為前端之后的首先需要牢牢關注的基石，如果有精力，應該關注語言的進步背后的推動力，這是能夠讓你一定意義上擁有以不變應萬變的能力。工具是你在目前的社區上，在工作中最常談論最常用上，它們具備一定的通用性，看上去能解決所有人的某些問題，但也更容易被革新。這部分需要關注，因為這是你能更好解決問題的方法，但不要過于沉迷于工具，隨著技術的發展，面對問題域的進一步復雜化，甚至其他工具的發展，新的工具會源源不斷的被發明，舊的工具一樣會周而復始的被拋棄，這個生命周期是一定存在的。

容納

所有在社區中出現的東西，都是為了解決它所在的場景中的問題而誕生的，存在即合理在這個語境下挺合用的，先開放的接受之后，明白自己想要用這個東西做什么： 學習用法? 學習解決問題的思路? 學習代碼的組織方式? 學習編程的技巧? 明確這個問題后，會發現自己的目的性就明確多了，也會發現學習的脈絡就會慢慢浮現上來。

好奇心

做前端需要有充足的好奇心，這個好奇心是指： 對所有不熟悉的東西都有興趣去了解一下; 了解之后會有興趣上手實踐一下; 實踐之后有興趣思考一下; 在合適的場景合適的時機應用一下，或者優化一下。綜合在一起，可以這樣來描述：

對新技術，新交互形式等新鮮玩意充滿好奇和探索的欲望。

從對用戶的認知，對業務的認識，對產品的理解，找到最合適的方式解決問題，比一直追在技術浪潮尖端學習來的幫助更大。

不要過于滿足于任何時刻的成果，學會時刻的自省，以及有克制的精益求精。

很慶幸，在我踏入職場不久就讓我接觸到了前端這個角色，讓我有機會把對美好設計感的追求和技術的力量疊在一起，在B類業務經歷的這段時間，讓我有更多的機會和責任去思考成為前端的追求，總算略有些成果，和大家分享。