騰訊Now直播前端工程化的實踐之路

騰訊Now直播前端工程化的實踐之路

受訪嘉賓 | 程柳鋒
編輯 | Yonie
在百花齊放的前端圈，層出不窮的組件框架已讓前端開發者目不暇接，另外，再加上業務和開發團隊的不斷髮展，前端開發人員面臨的問題愈來愈多。日漸突出問題主要爲：如何高效的與團隊成員進行合做開發？項目愈來愈多，不一樣技術棧的項目如何統一維護？如何制定和踐行統一的開發規範？如何高效的部署和發佈產品？
這個時候 前端工程化 概念的出現，解決了上面讓開發者頭痛的問題。它旨在制訂規範化的前端工做流，並規範統一項目的模塊化開發和前端資源，讓代碼的維護和互相協做更加容易更加方便。同時，讓你們可以釋放生產力，提升開發效率，更好更快地完成團隊開發以及項目後期維護和擴展。
可是前端工程化具體是如何實踐的呢？帶着這樣的問題，咱們採訪了參加本次 ArchSummit 全球架構師峯會的騰訊 Now 直播產品 IVWEB 團隊社區、工程化的負責人——程柳鋒，程老師與咱們分享了騰訊 Now 直播在前端工程化上的具體實踐方案。如下是本次的採訪內容：
InfoQ：請您先作下自我介紹吧。
程柳鋒：我是程柳鋒，來自騰訊，前後參與騰訊 NOW 直播、NOW 語音交友、手 Q 羣視頻、羣送禮等與直播相關的的泛娛樂產品的開發。另外我仍是整個騰訊 IVWEB 團隊社區、工程化的負責人。現階段主要關注團隊的工程化建設，包括新技術的預研和落地，另外也積極探索行業前沿技術好比：WebAssembly、PWA 等。
InfoQ：一線開發人員參與前端項目過程當中須要關注哪些因素？
程柳鋒：在產品迭代過程當中，前端的定位每每是處於應用層，負責 UI 開發和用戶交互體驗的工做。你們平常開發時接觸的 To C 的產品居多，好比 BAT、美團、滴滴等大廠的產品。這類產品的量級比較大，基本上日均 DAU 能達到幾百、幾千萬，甚至過億。所以，這類產品對用戶體驗要求很是高，一個微小的 JS 腳本錯誤很容易引起血案。
以咱們團隊爲例，對於每一位開發者都有較高的專業能力要求，一般概括爲三個要素。按照重要性順序以下：

• 首先，是質量，開發者作出來的項目，其質量必須獲得良好的保證，咱們也會在項目上線前經過完善的監控手段保障質量。好比：JS 腳本錯誤監控、接口成功率監控、測速監控、HTML/CSS/JS 加載成功率監控等等。
• 其次，是產品的性能。咱們但願頁面加載時首屏的白屏時間儘量短，至少達到秒開的加載體驗。另外，還須要保證在弱網絡的狀況下，頁面也可以很好的展現。

• 最後是研發效率，就是如何在較短的時間內，快速地進行業務需求的開發和上線。
  InfoQ：如今騰訊上線前端項目，或者說升級項目版本，大概須要多長時間呢？
  程柳鋒：上線時間會根據具體的項目類型地變化而變化。咱們內部總體採用敏捷開發模式，一般一個項目從啓動到上線在 2～3 周，其中一週爲開發時間，一週爲測試上線的時間。
  另外，對於重點攻堅項目咱們以前也有大膽的嘗試。舉個例子，在 2018 年年初時，直播領域裏的答題玩法特別火爆。各家直播平臺好比：花椒、映客、熊貓直播，包括騰訊、高德地圖、支付寶等都在作直播答題的應用。咱們當時作這種攻堅項目，第一個版本從產品方案設計到最後上線發佈僅僅花費兩週時間。相對來講時間仍是很是緊湊的，對一線開發人員做戰能力有着較高的要求。
  InfoQ：前端工程化是您負責的重要工做之一，它都包括哪些內容呢？
  程柳鋒：前端工程化是一個團隊的基礎設施之一，它更加偏向工程架構、研發流程相關的內容，主要有這樣幾個目的：

• 隨着業務的快速發展，產品需求爆炸式增加，團隊成員不斷擴充，前端工程化的首要目的就是知足快速發展的業務須要。前端工程化須要標準化研發方式、研發流程（開發、測試、發佈、線上監控），讓你們從建立項目到最終項目上線、監控使用相同的開發習慣。這個是前端工程化的主要目的。

• 第二個目的，把團隊的經驗（好比作項目時踩的坑、通過試驗得以驗證的新特性等）沉澱到腳手架和開發套件中，使其餘同窗在開發新項目時能夠複用這些經驗。

• 第三個目的是關注新技術的前端工程化落地場景，好比最近比較火的 Serverless、Flutter、小程序等技術。經過工程化的方式把新的技術與現有項目結合進行試驗，試驗成功後抽成腳手架和開發套件，其餘同窗後續開發這類工程也特別簡單，節省了其餘同窗再次探索新技術的時間。讓整個開發體驗更加順暢。
  InfoQ：前端工程化是何時提出來的？背景是什麼？
  程柳鋒：大約在 2010 年左右前端工程化的概念開始萌芽。前端工程化的提出，主要有如下兩個緣由：

1.業務場景的不斷的複雜，不少事情須要前端去承載。像 H五、跨端應用，以及如今 WebAssembly、PWA 等新技術，他們的出現都讓瀏覽器端能夠承載的事情更多了，不少業務邏輯由服務端、客戶端遷移到了前端。

2.2009 年 Node.js 的興起給前端工程化提供了工具層面的支持，如今你們寫的構建工具、腳手架工具、代碼規範檢查，以及咱們作的 Pre Render，都是在 Node.js 的基礎之上作的。前端工程化的概念還須要經過工具來加以踐行和佐證，咱們經過 Node.js 編寫 CLI 或基於 nw.js/Electron 的 GUI 工具，在項目的建立階段，你們可使用統一的命令來建立項目、頁面或組件；在項目的開發階段，針對不一樣技術棧的項目可使用不一樣的開發套件進行本地開發、調試、和規範檢查。
InfoQ：從 2009 年到如今也有 10 年的時間了，你以爲如今前端工程化大概發展到什麼階段了？
程柳鋒：前端工程化的價和團隊規模成正相關的關係，團隊規模越大，工程化的價值就更高。能夠分爲幾個階段：

• 第一個階段：初創的團隊，團隊人數大約在十人以內，這時候前端工程化的主要做用是規範開發、協做規範。這個階段團隊人數相對比較少，你們經過簡單的規範約束基本能夠知足需求。
• 第二個階段：團隊規模在快速擴大，內部員工流動比較大，這個時候讓你們都遵照以前制訂的規範是比較困難的。經過工程化的 CLI/GUI 工具、腳手架、開發套件和插件，保證項目從建立到本地開發、測試，再到最後的發佈、監控都可以正常的運轉。
• 第三個階段：團隊若是達到必定規模（大約在 100 人以上），或者多個部門共同參與前端工程化的建設，從而有效的避免不一樣部門重複造輪子的現象。
  InfoQ：在前端工程化的趨勢下，CLI 和 GUI 這兩個工具開發的背景是什麼？解決了什麼問題？
  程柳鋒：若是把前端工程化分層的話，CLI 和 GUI 就是在最頂層。它們是直接和開發者進行交互的，最核心功能是規範開發流程。CLI 是命令行的形式，GUI 是圖形界面的形式。中間層便是工具平臺和規範，開發者經過 CLI 或 GUI 便可調用工具平臺，快速打通與工具平臺、開發規範的聯繫。底層爲基礎設施。咱們目前已在五個業務場景應用了 CLI 工具，分別是五個不一樣技術棧的業務場景：商業化的運營活動、APP 內嵌的 H5 頁面、ReactNative、Serverless、組件。
  InfoQ：前端工程化的腳手架能爲開發人員縮短構建項目的時間，同時提升開發的效率，請您說一下前端腳手架的構建現狀。能夠從騰訊的構建現狀或者業界的構建現狀來說一下嗎？
  程柳鋒：這兩個均可以說一下。咱們先來聊一聊整個行業的形態，如今市場上比較流行的前端框架主要是有如下幾個：React、Vue、Angular、Weex。這些框架各自所對應的腳手架都只能開發本身技術棧的項目。而實際開發中，咱們須要面臨不一樣技術棧的開發場景，單一技術棧的腳手架沒法知足需求。
  其次，使用的官方腳手架所包含的功能是最基礎、最通用的。在騰訊的實際業務場景中，針對一些細粒度化的業務仍須要作二次定製。好比平常中須要上報的各類數據：監控信息、JS 數據、VIP 白名單日誌、接口接口調用成功率、首屏渲染時間、HTML/CSS/JS 加載成功率等，用行業通用的腳手架徹底不能知足咱們的要求。咱們在行業腳手架的基礎上進行維護，二次定製具備咱們業務特點的腳手架。
  咱們團隊目前在這個背景下作了一個更加通用的技術方案。該技術方案基於 Yeoman，在 CLI 裏面的集成了 Yeoman 的 Runtime。截止到如今爲止，咱們公司內部總共有十個腳手架左右，你們能夠共同維護這些腳手架，並進行二次定製。經過上層統一的 CLI 命令在建立項目時就能夠選擇使用哪一個腳手架。
  InfoQ：如今前端使用 Webpack 構建工具比較多，與以前使用過的構建工具相比，Webpack 的優勢是什麼？
  程柳鋒：我我的以前用了不少種構建工具，如 YUI Compressor、Grunt、Gulp、Fis3 和 Rollup 等，目前咱們已經完成大部分業務從 Fis3 切換到 Webpack4，其中他們的區別主要有如下幾點：
  1.從插件生態上來看，Webpack 相對 Fis3 擁有更高的維護頻率（即發版節奏快）。從 Webpack1 到 Webpack5，基本上每一年出一個新版本。目前 Webpack4 已經正式發佈了，Webpack5 也已經在 alpha 階段，整個社區 Webpack 貢獻者也不少，當你們遇到問題並提交 issue 至社區，問題均可以獲得解決。

2.另外，Webpack 能夠作的事情有不少。整個社區的 Loader、插件十分豐富。好比 HappyPack，其多進程多實例打包方案能夠實現快速打包，相對 Fis3 來講，其打包效率是很是高的。包括如今 Webpack 官方也原生提供了 thread-loader，也能夠經過它進行多進程多實例的快速打包，從而讓打包時間獲得極大的優化。

3.Webpack 和其餘構建工具的差異在於 Webpack 打包理念是革命性的。Webpack 把全部的資源都當作模塊（好比 JS、CSS 圖片、字體，或富媒體的文件等）。與其餘構建工具相比，Webpack 最顯著的特徵是它經過各類 loader 去處理模塊，這也是你們爲何一直叫 Webpack 模塊打包器的緣由。Grunt 和 Gulp 的構建過程都是以 Task Runner 的方式去作的。Gulp 是流式的構建，而 Grunt 每次的構建產物會存儲到本地的 tmp 目錄中，Gulp 是直接放到內存裏，構建的時候相對 Grunt 更快一點。
InfoQ：騰訊把構建工具從 Fis3 遷移到了 Webpack4？在切換的過程當中有沒有遇到什麼困難呢？又是怎麼解決的？
程柳鋒：咱們當時切換的時候確實遇到了不少困難。第一個困難是 Fis3 裏面支持了一些比較好的特性，而在 Webpack 卻沒有。這裏面也能夠舉一些咱們在實際遷移過程當中遇到的例子，好比說 Fis3 支持 inline 語法，能夠將 HTML 片斷引用到另一個 HTML 中，也能夠將一個圖片 inline 過來自動 Base64，還能夠合成雪碧圖，總的來講它能夠精細化的控制資源。但在 Webpack 中是不支持 inline 語法、雪碧圖的合成。咱們解決的方案是實現相關的 Loader，好比 inline Loader。對於雪碧圖的 sprites-loader，在項目遷移的過程當中咱們把 Fis3 的資源內聯語法 (?_inline) 和合成雪碧圖語法 (?_sprite) 作了下兼容，新舊項目中都支持了。
其次，Fis3 中支持資源引入時的絕對路徑寫法，在遷移至 Webpack4 的過程當中也須要對它作兼容支持。
還有一個比較大的差異就是打包方式的不一樣。用 Fis3 打包時是以 HTML 爲入口，但在 Webpack4 中是以 JS 爲入口，打包的入口發生了很大的變化。這時候，咱們也須要對以前的邏輯作些適配。
InfoQ：各個項目中使用的技術棧大不相同，這對項目組件化帶來了什麼樣的影響？
程柳鋒：這其實會帶來的一個最大的影響是，不一樣技術棧項目的組件沒法複用到另外一個項目。因此針對於組件化的複用，咱們也作了一些適配，固然，不是全部的組件都適配，咱們只是對基礎的組件作同構。上層的業務組件能夠複用同構好的基礎組件。同構相對來說比較難，但爲了以後維護的便利性也是值得的。最好仍是根據各自的技術棧實現不一樣的業務組件，並統一維護。
InfoQ：騰訊 NOW 直播產品在團隊工具鏈、規範等開發配套設施的建設過程當中遇到了哪些問題？
程柳鋒：這裏面咱們也是遇到了很多問題。我先從規範提及吧。咱們團隊成立之初，是從騰訊的 IMWEB 團隊孵化出來的，這時咱們的工具鏈大多延用他們的工具鏈。隨着這業務的快速發展，暴露出不少業務自身的痛點，原來的工具鏈沒法知足現有需求。爲了解決這個問題，咱們創建了新的工具鏈和規範。咱們首先創建了 Git 提交規範、Git 工做流規範、分支規範、README 規範、監控規範等。可是規範創建以後又面臨另外一個巨大挑戰：如何將這些規範落地實施呢？咱們在這方面作了不少嘗試：

• 將 ESLint 的檢查規則集成到咱們的基礎設施上，就是將 ESLint 集成到 CI 和 CD 的流程中。當你們提交代碼後，第一步會經過 ESlint 來檢查代碼是否經過，若是沒有經過的話，就會拒絕本次構建，固然這個 ESLlint 檢查只是增量檢查。若是經過纔會進行構建流程。這就是咱們 JS 規範的落地執行過程。針對 Git 分支規範和提交規範，咱們天天經過郵件掃描，查看前一百條的 Git 提交記錄格式是否正確，如有問題，咱們會郵件知會相關同窗。
• 業務監控告警的規範執行，主要是靠技術負責人 Review，在項目每次發佈上線以前，技術負責人會 Review 監控上報的項有完好失。同時咱們根據業務的重要性、訪問量等指標將業務分爲 3 個級別：重要業務、經常使用業務、普通業務。不一樣級別的業務的監控要求也是不同的。
• 除此以外咱們還須要強制地將重要業務加到咱們的 CI 和 CD 流程裏，就是單元測試和端對端的測試，每次代碼 Commit 都會異步的經過騰訊的藍盾進行單元測試和端對端測試，若是測試用例不經過，則不容許發佈上線。

另外在工具建設的落地方面，咱們會作不少工具平臺，好比監控平臺、移動測試代理、組件平臺等，但這些平臺怎麼落地？咱們也作了一些操做。以監控平臺爲例，咱們會把每一個業務對應的 JS 錯誤 ID、JS 報錯率統計出來，並作一下排名。對於排名靠後的項目，會把相關人員、業務的名單展現出來，並通知相關的技術負責人、業務老闆等。這個作法仍是比較好的，有利於你們及時發現問題和解決問題，同時也幫助整個團隊改進工具平臺。
InfoQ：在前端工程化的發展過程當中，騰訊 Now 直播產品經歷了怎樣的技術架構變化？
程柳鋒：一開始騰訊前端工程化的建設與其餘公司仍是有必定的差距，甚至說是落後的。最開始咱們團隊的前端工程化侷限於 Fis 構建的工程化。Fis 能夠很好支持本地開發，但不支持建立項目、單元測試、端對端測試、代碼檢查的工程化。因此咱們第一階段作的事情就是換掉 Fis，使用 Webpack 做爲咱們的構建工具。
以前，整個騰訊 CI 這塊的建設比較落後，CI 作得事情也比較有限。在作了腳手架和構建工具切換後，咱們團隊搭建了 Jenkins，以便於代碼的可持續集成。
搭建了 Jenkins 以後，接下來慢慢的遷移到整個公司，並接入了橘子 CI（Orange CI），藉助 Orange CI 把不少 CD 的事情也一塊兒作了。由於以前接入的 CI 還不完全，咱們 CI 完成以後，開發者仍然須要在平臺上面手動的點擊發布，預上線發佈仍是有不少的人工操做。但咱們 CI 完成以後，每次 CI 完成以後它會自動構建出一個包。

• 若是是正常的 push，默認狀況下，構建出來的包會自動的部署到測試環境，完成測試環境的部署任務。

• 若是打了一個 tag（就是運行 Git tag），或者在 CLI 運行了 deploy 的命令，這時它會自動的幫咱們把構建出來的包發送到線上。對於離線包，它也會發一個灰度離線包，咱們只須要驗證沒問題以後，本身再手動的發一個離線包便可。在有了 CI、CD 作支撐後，前面提到的規範和端對端的測試用例、單元測試等，均可以很好的集成進來了。
  這就是咱們 Now 直播產品整個前端工程化的技術架構，接下來，咱們也會去重點探索一下小程序、Serverless 的前端工程化要怎麼作，這也是目前騰訊開源協同的 Team 在關注的事情。
  InfoQ：那如今騰訊這邊的前端的發佈系統已經能夠實現項目自動部署了嗎？
  程柳鋒：如今已經徹底實現自動發佈了。CI 和 CD 的過程很大程度上提高了咱們的開發效率。以前若是手動發佈項目，你須要作不少操做。可是如今只需在不一樣的發佈系統裏面點擊一下就能夠實現項目發佈，發佈時間從以前 15 分鐘優化到僅僅一條命令就完成。
  InfoQ：您認爲前端工程化在將來有哪些機遇和挑戰呢？
  程柳鋒：我認爲有如下幾個機遇：

1.前端工程化能夠作不少事情，前面提到了有三個階段，那麼第四個階段就是中臺化，咱們能夠聯合多個部門共建前端工程化，讓它的生態和體系更加完善，從而有效的避免重複造輪子的事情，這是每一個公司將來都要重點實踐的事情。

2.前端技術發展異常活躍，新的技術和框架不斷的出現。對於新的技術方案，咱們要及時的把它們整合進來，並探索它們的工程化，好比說像小程序、Flutter、Serverless 等這些新技術的工程化方案。

3.咱們認爲前端工程化將來的定位將更加超前。新技術的預研有很大一部分是放在前端工程化中來作的。舉個例子，以前咱們的項目是 React 16.2.0 版本，這個版本咱們用了一年多，但隨着 React 框架不斷的發佈，當 React 發佈到 16.8.0 的時候，React 會帶來不少新特性，若是再用以前的 16.2.0 版本，開發者將沒法感知 React 的新特性。這時候，經過前端工程化的方式，能夠幫助你們快速的體驗新特性。另外，還包括一些技術方案的嘗試，好比像 WebAssembly、PWA 等，經過前端工程化的方式，可以更好的賦能咱們業務。