阿里9年，我總結的前端架構演進3大階段及團隊管理心法

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

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

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

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

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

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

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

　　第一站：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類業務經歷的這段時間，讓我有更多的機會和責任去思考成為前端的追求，總算略有些成果，和大家分享。

　　作者介紹

　　趙振宇，2004年畢業於上海海事大學，2008年加入阿里巴巴國際事業部，從一線工程師開始阿里的前端之旅。先後負責阿里巴巴國際事業部前端團隊，阿里巴巴企業事業群前端團隊。目前擔任阿里巴巴企業事業群(BBC)體驗技術中臺負責人。10多年大型網際網路企業及自己創業的經驗。在阿里期間，主要是從事國際化站點的前端業務解決方案和應用架構的技術架構和技術管理工作。主要專長和興趣包括：UI領域標準化建設、網際網路電商平臺與應用架構演進、大型企業級架構中前端的分層治理、前端人員的發展與培養。