前端工程化

做者： @gauseen

背景

前端技術飛速發展，各類技術層出不窮，不再是隻會 切圖 + jQuery + CSS 就能夠行走天下的時代。
隨之帶來的就是 web 應用的複雜度愈來愈高，出現問題的機率也越大。

如何解決多人協同高效開發？如何保證項目可維護性？如何高質量交付任務？成爲每一個前端開發工程師值得思考的一個問題。

爲解決上面的問題，大佬們引入了前端工程化這個概念。

什麼是前端工程化

將前端開發流程，規範化、標準化、自動化。

前端工程化

項目腳手架

項目腳手架能夠在新建立一個項目時，簡單敲幾行命令就能夠生成初始化代碼，直接進行頁面級開發。讓開發更加專一於業務邏輯層，而不是各類配置項。

如 vue-cli 腳手架，就能夠一鍵式快速構建 Vue.js 應用開發環境。

我也開發了一個很方便學習的腳手架 feseed-cli，目前支持的模板源碼在這裏查看。
這樣就能夠根據公司業務抽離出來一個基礎項目模板，當須要啓動新項目時，直接敲幾行命令就能夠啦，提升開發效率，統一了公司前端項目技術棧，開發規範等。

構建工具

任何重複有規律的編碼，均可以用程序方來解決。構建工具大大提升了開發效率，解放了重複勞動力，如：壓縮、打包、單元測試等操做，加強了前端開發的可玩性。

構建工具在前端工程化中，像是扮演一個「管理者」的角色。工程化中一系列的規範化、標準化、自動化都須要配合構建工具來實現。

經常使用的構建工具，以下：

• webpack：一個模塊打包器，主要用於打包 JavaScript 文件，更好的在瀏覽器中使用，webpack 能夠轉換、捆綁、打包處理任何資源（v4.0 支持零配置），經常使用於 Web 應用開發
• parcel：快速，零配置的 Web 應用程序打包程序
• rollup：JavaScript 的模塊打包器，它推崇使用標準化的 ESM 規範進行編碼，而不是 CommonJS、AMD、CMD。經常使用於工具庫開發
• gulp：是任務運行（task runners）的流式（stream）構建系統，與 grunt 功能相似，特色是用流式編寫任務代碼，gulp 的流實現，每一個任務能夠並行運行，這使它比 grunt 快不少
• grunt：任務運行（task runners）構建工具，grunt 中的每一個任務都是一系列不一樣的插件配置，這些插件以必定順序一個接一個的執行
• browserify：與 webpack 功能類似，能夠在瀏覽器裏使用 require('modules') 語法的打包工具，就像在 node 環境引用資源同樣
• pikapkg/web：安裝 npm 依賴項，在瀏覽器中運行。不須要 Browserify、Webpack

JavaScript 模塊化

ES6 以前沒有模塊（module）系統，這使得 js 大型應用沒法拆分出小的 module，很不方便開發和維護。如：nodejs 中可使用 require('module')

爲了解決這個問題，大牛們定製了一些模塊化方案，大致可分爲如下幾種：

• AMD（Asynchronous Module Definition）：異步模塊定義，依賴前置

  • requirejs：AMD 規範的表明做

• CMD（Common Module Definition）：通用模塊定義，惰性執行，依賴後置

  • seajs：CMD 規範的表明做
• CommonJS：服務端模塊化方案，同步加載
• UMD（Universal Module Definition）：AMD + CommonJS

在 ES6 內置支持 ESM（ECMAScript Module） 模塊系統，有以下特色：

• 借鑑了 AMD 和 CommonJS 規範的優勢
• 支持異步加載、懶加載
• 語法比 CommonJS 更緊湊
• 能夠對結構進行靜態分析（用於靜態檢查，優化等）
• 循環依賴的支持比 CommonJS 更好

代碼規範

每一個人的代碼風格都不相同，雖然咱們提倡多樣性，可是在一個團隊中，同個項目有不一樣代碼風格，那即是一種災難。
不利於項目後期維護，新人熟悉項目成本高

因此，咱們須要一塊兒討論，根據每一個人開發習慣，制定統一的代碼開發規範

• 規範有 2 大類

  • 一種是 HTML、css、js 原生開發規範，js 經常使用的有 standard（推薦）、eslint 規範，css 經常使用的有 stylelint（推薦）、csslint 規範，而 HTML 相對來講沒有太苛求具體規範
  • 另外一種，根據特定框架（如：vue、react），規定的一些開發規範

在使用 vue-cli 腳手架初始化項目時，會有相關 js 規範配置選擇，這裏我比較推薦 standard 規範。
由於 standard 規範有比較好的一個特色，無須配置，史上最便捷的統一代碼風格的方式。
這樣能夠爲團隊節省不少制定規範所浪費的時間，讓開發沒必要糾結於代碼規範，把精力放在代碼設計、開發上。

固然啦，蘿蔔白菜各有所愛，還有不少大公司所推出的規範也可使用，如：Airbnb JavaScript Style Guide、騰訊 Alloyteam 代碼規範 等。

爲了更具體的展現如何配合 git 鉤子，強制規定代碼規範，我寫了 用 git 鉤子, 檢測 js 代碼規範性（eslint、standard） 文章，具體講解了，如何在項目中從零配置 js 規範。

咱們對特定框架（vue.js）的編碼規範也參考了不少規範文章，作了許多討論。從目錄規範到具體開發細節都有了明確規定，具體可看這裏

版本控制（Git）

Git 是個很好用的代碼版本控制工具。在團隊協做時，也衍生出一些使用規範，幫助咱們提升開發效率、質量。

• 保證項目 分支圖（Graph） 的簡潔性
• 約定統一的提交消息（Commit Message）

爲何要保證項目分支圖的簡潔性？

咱們要達到的目標是，任何一個新人，當看到項目提交記錄分支圖時，就能知道這個項目的迭代大體過程，有助於項目理解和管理。

分支圖簡潔的重要性，對好比下：

以下圖，提交分支圖錯綜複雜，根本看不出有意義的信息

以下圖，分支圖很是簡潔，可讀性高，能夠清晰的知道代碼提交歷史，方便回退等操做

如何作到提交信息分支圖的簡潔性？

• 一個新需求，只需建一個 branch，多個開發人可在同一個分支開發，提交前，先用 git pull --rebase，而後再 git push 推到遠程。解惑 git rebase
• 禁用 git push -f
• 團隊 leader，要統一處理各個子分支開發完成後合併到主分支
• 每次部署新版本後都要更新 master 分支，並在最新 commit 處，新建 tag，用於標記當前應用版本
• 線上有 Bug 時，基於 master 分支，新建 hotfix-xxx 分支去處理 Bug

爲何要約定統一的提交消息（Commit Message）？

若是每一個開發人員都按照本身的意願去提交消息，那麼整個項目的提交歷史將會很難分辨提交了哪方面的內容。還有見到提交信息是 123456 ！！

因此，咱們須要 Commit Message 規範來限制開發人員提交信息的多樣性，來提升 Git Commit Message 的可讀性。

規範也有不少種，這裏比較推薦 conventional-changelog/commitlint 規範，不少知名項目也使用了該規範。

Mock 數據

先後端分離式開發已經很常見了，爲了提升開發效率，先後端並行開發，mock 數據(造假數據) 已是個不可避免的問題。 對前端來講 mock 數據的方式有不少種：

• Mock.js 模擬數據生成器

  • 須要前端手動去寫 mock 數據代碼，比較麻煩
  • 每一個項目都要有一套 mock 代碼，複用率底
  • 沒有 GUI 可視化界面，不方便後端開發查看接口、字段等 api 信息

• easy-mock 是一個可視化，而且能快速生成模擬數據的持久化服務

  • 支持可視化界面
  • 支持協同編輯
  • 支持 swagger，可基於 swagger 快速建立項目接口
  • 支持 Mock.js 語法
  • 支持接口預覽，等等
  • 免費開源，私有化部署簡單

• RAP 和 RAP2 阿里媽媽出品，開源接口管理工具 RAP 第一代和二代

  • 支持可視化界面
  • 支持協同編輯
  • 支持 Mock.js 語法
  • 不支持 swagger 數據導入，但支持 JSON 格式數據的導入導出
  • 免費開源，但私有化部署相對繁瑣

• YApi 是一個可本地部署的、打通先後端及 QA 的、可視化的接口管理平臺

  • 支持可視化界面
  • 支持協同編輯
  • 支持自動化測試, 對 Response 斷言
  • 基於 Json5 和 Mockjs 定義接口返回數據的結構和文檔
  • 支持 swagger、postman、json、har 數據導入
  • 免費開源，私有化部署簡單

以上，我比較推薦 YApi 平臺。

測試

測試種類有不少

• 單元測試（Unit Test）：針對函數或模塊的測試
• 集成測試（Integration Test）：針對總體產品的某個功能的測試，又稱功能測試
• 端對端測試（End to End Test）：從用戶界面直達數據庫的全鏈路測試

對於基礎模塊，如：經常使用方法工具庫，有必要作單元測試

對於穩定的核心業務，如：支付系統、營銷系統有必要作測試

對於非核心業務，功能不穩定的部分，不建議開發自動化測試用例，寫測試用例很浪費時間，有時剛寫完，需求又變了，還要從新寫測試，對人力也是一種浪費。

比較經常使用的測試工具備：

• jest
• mocha
• ava
• vue-test-utils Vue.js 官方的單元測試實用工具庫

線上部署

之前，發佈新版本的時候，是用手動發佈代碼的方式，效率低，出錯機率高。

如今，利用 Jenkins 實現自動化構建、測試和部署，大大提升了發佈效率，下降了出錯率。

錯誤監控

錯誤監控工具，以下：

• Sentry ：開源免費，可跨平臺的應用程序監視，着重於錯誤報告
• FunDebug：收費
• 應用實時監控服務 ARMS（阿里出品）：收費

線上錯誤監控，是應用發佈到線上後很重要的一環，方便預警、統計、追蹤、排查、復現 Bug 等。

歡迎關注無廣告文章公衆號：學前端

參考

• 從淘寶前端工程化演進，看工程化之路如何「私人訂製」
• 持續集成是什麼？
• 廖雪峯 Git 教程
• NPM vs. Bower vs. Browserify vs. Gulp vs. Grunt vs. Webpack