從阿裡前端工程化中台實踐，看中台建設的舍與得

作者|朱華軍（阿大）

出品|InfoQ&阿裡巴巴新零售淘系技術部

導讀：随着前端技術不斷從 Web 延伸至各種“端”，大前端的概念早已成為業内共識。伴随着大前端的發展，與之相對應的前端工程體系也在不斷拓展邊界，僅僅隻是建構、工具和規範等正常方式已經不足以表達當下前端工程所涉及的領域。

嘉賓介紹：

朱華軍（阿大），阿裡巴巴淘系技術部進階前端技術專家。2009 年加入淘寶網，負責過淘寶交易、商品等基礎業務及機票彩票、一淘等創新業務。2013 年開始專注于前端工程化領域，推動開發工具、流程和規範的統一，完成淘寶近百人前端團隊研發模式的整體更新。目前負責阿裡集團前端工程化中台的建設。

前言：

近日，阿裡巴巴進階前端技術專家朱華軍（阿大）受 InfoQ 采訪邀約，分享了阿裡集團前端工程化中台的實踐過程，以及實踐背後的經驗與思考。他在采訪中強調，前端工程化一定是大趨勢，但不建議大家盲目地追求工程化，對于大部分規模不大的前端團隊而言，工程體系的建設和規範并不是當務之急。

接下來，阿大将在 QCon 全球軟體開發大會（北京站）2020 擔任大前端大工程專題出品人，為大家帶來各大廠前端團隊在工程領域不斷拓展思路、換道創新中沉澱下來的經驗和實踐，感興趣的讀者可以關注。以下為采通路答實錄。

Q：您從 2013 年開始專注于前端工程化領域，并完成了淘寶近百人前端團隊研發模式的整體更新，能否先總體介紹一下淘寶前端團隊研發模式的發展曆程，期間一些重要的節點。

朱華軍（阿大）：

我是 09 年加入的淘寶，那時淘寶前端的研發體系還比較原始，代碼管理是基于 SVN 的，所有前端代碼都在一個代碼倉庫裡。每周有兩個釋出視窗期，SCM 會提前拉好開發分支，大家在一個分支上開發、內建和上線。那個時候前端的代碼是所寫即所得，不需要編譯建構什麼的，本地的開發環境相對也簡單，基本以文本編輯器為主。

大概到了 13 年的左右，NodeJS 和 Git 開始流行，淘寶前端聯合 SCM 團隊基于開源的 Gitlab 在集團内搭建了 Git 托管環境，前端是最早将代碼從 SVN 全部遷移到 Git 進行管理的技術崗位，這個決策對後續阿裡巴巴前端工程體系建設起到了非常重要的影響。由于 Git 在分支管理特性上的優勢，原先前端的內建開發模式慢慢演變成了基于 Git 分支和 Gitlab Web Hook 的半自動化模式。

另外 NodeJS 的崛起也快速促進了我們内部前端本地開發工具生态的完善，各種本地 Command Line 工具如雨後春筍般湧現。百花齊放的繁榮之後必然的結果就是規範和一統，彼時剛好集團在推行中台戰略，前端研發工程體系順勢走上中台化道路。

Q：集團内部是什麼時候确定要做前端工程化中台的？做這個決定的背景是什麼樣的？面臨的最大挑戰是什麼？期望中台解決什麼問題？

17 年初的時候吧，在這之前我們已經統一了淘寶前端團隊的工程體系，有了完善的本地開發工具生态，标準化了本地的開發和調試。另外還搭建了一套線上釋出流程，孵化了如雲建構（代碼線上建構）、門神（代碼靜态掃描）等前端工程基礎設施。

那一年初團隊在做規劃的時候，大家對前端工程體系接下來發展方向有一些争議：

• 第一個觀點認為我們應該将本地的研發工具統統搬上雲，包括線上 IDE、線上 Dev 等，線上化一定是未來的趨勢；
• 第二個觀點認為我們應該輸出淘寶前端的工程能力到整個阿裡巴巴集團，淘寶前端的工程體系建設已經站在了集團的制高點，應該順勢推進整個集團前端研發體系的規範化。

在當時的情況下，集團中大部分 BU 的前端體系或多或少都源自淘寶前端，中間有着千絲萬縷的關系，另外還有一個外部因素就是大家已經非常熟悉的阿裡提出的中台戰略，在集團中台戰略大的趨勢下我們最終毅然決然地選擇了建設阿裡巴巴前端工程中台。

當然這不是說第一件事情就不重要，恰巧在經曆過前端工程中台的建設後，我們目前在做的就是 IDE 和線上研發能力。

阿裡是一個龐大的經濟體，各事業群和事業部加起來有幾十上百個大大小小的前端團隊，推進如此多的團隊來規範前端研發體系的阻力是巨大的。加之每個前端團隊當下的前端工程體系建設程度不一樣，對标準化前端工程開發的了解和需求也都不一樣，如何說服并協調推進如此衆多的前端團隊，是我們做這件事情遇到的第一個難題。

簡單說下我們是如何解決的，類似的問題我想稍微有規模一點的跨團隊協作項目應該都會碰到，我們首先 需要得到自上而下的支援。阿裡巴巴集團内不同的技術棧都有一個技術委員會，前端也有一個阿裡前端技術委員會。技術委員會的成員一般都是各事業群較大規模前端團隊的 Leader，每年委員會會發起幾個技術項目，并協同集團内資源合力推進。經過努力，前端工程中台争取到了委員會其中一個技術項目。有了自上而下的支援，很多事情推進就友善多了。不過光靠自上而下推動也是不行的，畢竟技術體系的更新改造對日常業務的正常進度肯定是有影響的。

另外 對于大部分規模不大的前端團隊而言，工程體系的建設和規範并不是當務之急。是以我們首先選擇集團内規模最大的 TOP 5 前端團隊進行推進，這些團隊對于規範前端研發的需求更加強烈，并且本身也有一定的工程底子積累，溝通可以更加順暢，彼此之間也有更多的了解和認可。當幾個較大前端團隊統一之後，其它團隊就輕松很多了，甚至大部分小團隊是主動要求接入前端工程中台的。

大部分的基礎技術體系建設逃不開三個關鍵字：效率、品質和成本。前端工程體系的建設也是緊緊圍繞着這三個關鍵字，通過标準化的研發能力和統一的流程規範來限制研發過程中的不确定性，進而提升研發效率和品質。效率和品質提升了，成本自然就降了。而前端工程中台的目的是期望降低所有前端團隊達成這一目标的門檻，不管團隊在什麼階段、是何種規模，都能借助前端工程中台快速落地适合自身組織形态和技術特點的前端工程方案。

Q：阿裡前端工程化中台能夠提供哪些服務和技術能力？在通過中台提高前端研發效率上，能否列舉一個具體示例進行說明？

在我個人的了解裡，标準化和開放一定是任何一個中台必須具備的能力。這兩者看上去似乎有點沖突，卻是我們在建設前端工程中台時切實的感受和總結。比如我們統一了靜态源站和釋出流程，規範了本地工具指令入口和裝載更新模式，更是推進了标準化的線上建構體系與代碼檢查體系的建設。關于開放，前面有講到前端工程中台的目的是降低所有前端團隊工程體系建設的門檻，是以賦能必然是中台的使命之一，開放是賦能最直接有效的方式。

完善的工程體系必然會幫助團隊提升研發效率，而工程中台的使命是幫助每個團隊更高效的完善工程體系的建設。對于中台而言，研發效率的提升其實并不是最直接的收益，而是全局性的收斂和管控能力。

我舉個收斂管控方面的例子：18 年集團整體推進安全生産政策，所有的線上變更必須接入統一的變更管控平台，送出變更單後允許進行線上變更。這個時候工程中台的價值就展現出來了，因為我們已經經過一年多的努力收斂了所有前端的釋出流程，整個集團所有前端的釋出接入統一變更管控幾乎沒有成本地實作了，這在推進前端工程中台之前是無法想象的，如果沒有前期的收斂根本無從下手。

Q：阿裡前端工程化中台目前推進情況如何？與您的預期相符嗎？您理想的狀态應該是什麼樣的？

目前的整體進展還是比較符合預期的，在流程規範和标準化方面我們已經取得了非常好的效果，并且在推進工程中台的實踐過程中積累了不少優秀的能力平台，這些都是寶貴的資産。

當然等着我們去做的事情還很多，有兩件事情是我們後續的重點。第一件事是開放的 IDE 生态建設，經過大半年的封閉開發我們已經完成了代号為 “開天” 的 IDE Framework 的研發，IDE Framework 是 IDE 的核心，通過 “開天” IDE Framework 建構的各種 IDE 實作（Web 或本地）來打通研發生态。待再進一步完善後，我們将開源整體的 IDE 解決方案，包括開放的擴充生态體系、Web IDE 容器側能力等。未來阿裡前端的工程體系一定是圍繞着 IDE 展開的。

第二件事情跟開放相關，目前我們所有的工程能力都是服務于内部員工的，我們期望借助阿裡雲能夠以平台化、體系化和産品化地方式輸出阿裡的前端工程實踐，服務社群服務行業，為推進國内前端的發展出一份力。

Q：在前端工程化中台推進過程中，來自前端團隊的回報是什麼？有沒有遇到什麼困難，你們是如何解決的？

困難肯定有，前面也有講到，在阿裡巴巴如此龐大的體系内，多部門的協調和落到遇到阻礙在所難免，關鍵是找到正确的解決方法。在每個前端團隊中，對于工程化帶來的收益在個體與團隊整體的體感差異是很大的。

這個怎麼了解呢？我在很多場合表達過，越是完善的工程體系對個體的限制往往是越強的，帶來的結果可能是個體的效率反而是下降。是以我們在推進工程中台時，來自一線的反對和抱怨聲是蠻常見的。但如果我們換個視角，從團隊整體的角度去看待效率這個問題，一定是能達到 1+ 1 大于 2 的效果的，特别是規模越大的團隊效果越明顯。是以在前端工程中台的建設和推進中，我們優先考慮的都是如何幫助團隊整體獲得更高的收益。

Q：您認為前端工程化中台是大勢所趨嗎？推進過程中可能還會遇到哪些挑戰？

前端工程不是萬金油，它是在特定場景及特定時期的針對性解決方案，越是完美、越是高效的工程解決方案越是被所服務的組織結構和技術架構所限制，是以對我合适的前端工程解決方案對你未必合适。

前端工程化一定是大趨勢，但不建議大家盲目地追求工程化。任何體系或平台的建設都是需要投入成本的，還是要結合自身組織特點，先清楚地認識自己所處的階段，計算清楚投入産出比。

• 如果是 10 人以下的小規模的團隊，适當制定研發規範即可；
• 10 - 30 人規模的團隊可以制定一些研發規範、落地工具和流程；
• 30 人以上團隊規模就要開始體系化思考前端工程能力的建設了。

中台亦是如此，不要為了中台而中台，先想明白要解決什麼問題。

Q：機器學習在大前端領域也正成為一項越來越重要的技術能力，阿裡前端團隊在智能化方向上還有哪些探索工作？您如何看待前端智能化的現狀和未來發展？

阿裡前端布局機器學習領域相對較早，前端智能化體系建設已經連續兩年作為經濟體前端委員會的技術項目之一了。并且也已經有了相關的成型産品：imgcook（

https://www.imgcook.com/

）。imgcook 基于大資料機器學習，可以智能地将設計稿轉換成前端代碼，在 2019 年雙十一開始就已經大量應用到會場頁面的開發。還原精度業界領先，并且支援自定義擴充 DSL，大家有興趣可以通路官網詳細了解。

基于機器學習的智能化輔助開發是前端領域的下一個技術風口， 我所知道的國内國外不少大公司都在做。這個領域在基礎技術方面的發展已經比較完備，不過目前前端在這方面的人才儲備還非常不足，有興趣的前端同學可以多了解了解。

Q：您将在本次 QCon 北京 2020 上擔任“大前端大工程”專題的出品人，能否跟我們詳細談談所謂“大前端大工程”指的是什麼？這個專題将會跟大家重點分享哪些内容？

大前端的概念應該不需要過多介紹了，傳統的 HTML、CSS 和 JS 已經完全無法定義當下的前端。大工程其實是跟大前端相對應的，僅僅隻是建構、工具和規範等正常方式也已經不足以表達當下前端工程所涉及的領域。為了提升研發效率、為了保障大規模協同、為了激發業務創新，各大廠的前端團隊在工程領域不斷拓展思路，突破界限；優秀的初創企業也從中另辟蹊徑，換道創新。如此繁榮的前端工程生态也隻有叫大工程才配得上了。

本屆 QCon 該專題将遵循 “大前端大工程” 的定位徹底打開前端工程實踐領域，我們會邀請國内各大廠的優秀前端團隊來分享如何通過創新工程等手段來解決極限業務訴求。除了實踐之外還會有幾個前端工程相關的基礎技術（Webpack 等）分享，這塊以海外嘉賓為主。

Q：大前端領域涉及的工程能力越來越多樣化、複雜化，這是否意味着前端将進入一個新的階段？前端工程師如何做好準備？

其實前端一直在不停的進入新階段，“學不動了” 這個笑話很好地闡釋了前端技術領域的疊代變化之快。我認為工程能力的完備程度，可以非常直接地展現一個技術的成熟度。完善的工程能力必然催生工作内容的細分，并有效降低細分領域的入門門檻。同時也會必然會淘汰大量低級勞動力，特别是在自動化、智能化方向的工程實踐，未來一定會淘汰一大批入門級的前端工程師。

如果一定要給建議的話，對于那些目前已經在前端崗位的同學，我建議要找到自己在前端的細分領域，然後持續深入下去。

We are hiring

淘系技術部依托淘系豐富的業務形态和海量的使用者，我們持續以技術驅動産品和商業創新，不斷探索和衍生颠覆型網際網路新技術，以更加智能、友好、普惠的科技深度重塑産業和使用者體驗，打造新商業。我們不斷吸引使用者增長、機器學習、視覺算法、音視訊通信、數字媒體、移動技術、端側智能等領域全球頂尖專業人才加入，讓科技引領面向未來的商業創新和進步。

請投遞履歷至郵箱：[email protected]