資安

從阿里前端工程化中臺實踐,看中臺建設的舍與得

1.jpeg

作者|朱華軍(阿大)
出品|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]

Leave a Reply

Your email address will not be published. Required fields are marked *