前端工程化的理解

一、總結

一句話總結：

前端工程化是使用軟件工程的技術和方法來進行前端的開發流程、技術、工具、經驗等規范化、標准化，其主要目的為了提高效率和降低成本，即提高開發過程中的開發效率，減少不必要的重復工作時間。

而前端工程本質上是軟件工程的一種，因此我們應該從軟件工程的角度來研究前端工程。

 

1、前端工程化就是為了讓前端開發能夠“自成體系”，個人認為主要應該從模塊化、組件化、規范化、自動化四個方面思考？

模塊化：簡單來說，模塊化就是將一個大文件拆分成相互依賴的小文件，再進行統一的拼裝和加載。

組件化：從UI拆分下來的每個包含模板(HTML)+樣式(CSS)+邏輯(JS)功能完備的結構單元，我們稱之為組件。

規范化：規范化其實是工程化中很重要的一個部分，項目初期規范制定的好壞會直接影響到后期的開發質量。

自動化：前端工程化的很多臟活累活都應該交給自動化工具來完成。

 

 

二、前端工程化的理解

轉自或參考：前端工程化的理解 - 簡書
https://www.jianshu.com/p/88ed70476adb

 

什么是"前端工程化"？

目前來說，web業務日益復雜化和多元化，前端開發從WebPage模式為主轉變為WebApp模式為主了。前端的開發工作在一些場景下被認為只是日常的一項簡單工作，或只是某個項目的"附屬品"，並沒有被當做一個"軟件"而認真對待（無論是產品負責人還是開發者）。

在模式的轉變下，前端都已經不是過去的拼幾個頁面和搞幾個jq插件就能完成。當工程復雜就會產生許多問題，比如：

• 如何進行高效的多人協作？
• 如何保證項目的可維護性？
• 如何提高項目的開發質量？
• 如何降低項目生產的風險？
• ...

前端工程化是使用軟件工程的技術和方法來進行前端的開發流程、技術、工具、經驗等規范化、標准化，其主要目的為了提高效率和降低成本，即提高開發過程中的開發效率，減少不必要的重復工作時間，而前端工程本質上是軟件工程的一種，因此我們應該從軟件工程的角度來研究前端工程。

"前端工程化"里面的工程指軟件工程，和我們一般說的工程是兩個完全不同的概念。

• 工程是個很泛泛的概念，甚至可以認為建了一個git倉庫就相對於新建了一個工程；
• 軟件工程的定義是: "應用計算機科學理論和技術以及工程管理原則和方法，按預算和進度，實現滿足用戶要求的軟件產品的定義、開發、和維護的工程或進行研究的學科"（GB/T11457-2006《信息技術 軟件工程術語》）。

如何做"前端工程化"？

前端工程化就是為了讓前端開發能夠“自成體系”，個人認為主要應該從模塊化、組件化、規范化、自動化四個方面思考。

模塊化

簡單來說，模塊化就是將一個大文件拆分成相互依賴的小文件，再進行統一的拼裝和加載。

• JS的模塊化

  在ES6之前，JavaScript一直沒有模塊系統，這對開發大型復雜的前端工程造成了巨大的障礙。對此社區制定了一些模塊加載方案，如CommonJS、AMD和CMD等。

  現在ES6已經在語言層面上規定了模塊系統，完全可以取代現有的CommonJS和AMD規范，而且使用起來相當簡潔，並且有靜態加載的特性。

  1. 用++Webpack + Babel++將所有模塊打包成一個文件同步加載，也可以搭乘多個chunk異步加載；
  2. 用++System+Babel++主要是分模塊異步加載；
  3. 用瀏覽器的<script type="module">加載。

• css的模塊化

  雖然SASS、LESS、Stylus等預處理器實現了CSS的文件拆分，但沒有解決CSS模塊化的一個重要問題：選擇器的全局污染問題。

  按道理，一個模塊化的文件應該要隱藏內部作用域，只暴露少量接口給使用者。而按照目前預處理器的方式，導入一個CSS模塊后，已存在的樣式有被覆蓋的風險。雖然重寫樣式是CSS的一個優勢，但這並不利於多人協作。

  為了避免全局選擇器的沖突，需要制定CSS命名風格：

  • BEM風格
  • Bootstrap風格
  • ...

  但是這畢竟是弱約束。所以很贊同一句話：

  與其費盡心思地告訴別人要遵守某種規則，以規避某種痛苦，倒不如從工具層面就消滅這種痛苦。

  從工具層面，社區又創造出Shadow DOM、CSS in JS和CSS Modules三種解決方案。

  • Shadow DOM是WebComponents的標准。它能解決全局污染問題，但目前很多瀏覽器不兼容，對我們來說還很久遠；
  • CSS in JS是徹底拋棄CSS，使用JS或JSON來寫樣式。這種方法很激進，不能利用現有的CSS技術，而且處理偽類等問題比較困難；
  • CSS Modules仍然使用CSS，只是讓JS來管理依賴。它能夠最大化地結合CSS生態和JS模塊化能力，目前來看是最好的解決方案。Vue的scoped style也算是一種。

• 資源的模塊化

  Webpack的強大之處不僅僅在於它統一了JS的各種模塊系統，取代了Browserify、RequireJS、SeaJS的工作。更重要的是它的萬能模塊加載理念，即所有的資源都可以且也應該模塊化。

  資源模塊化后，優點是：

  • 依賴關系單一化。所有CSS和圖片等資源的依賴關系統一走JS路線，無需額外處理CSS預處理器的依賴關系，也不需處理代碼遷移時的圖片合並、字體圖片等路徑問題；
  • 資源處理集成化。現在可以用loader對各種資源做各種事情，比如復雜的vue-loader等等；
  • 項目結構清晰化。使用Webpack后，你的項目結構總可以表示成這樣的函數： dest = webpack(src, config)。

組件化

從UI拆分下來的每個包含模板(HTML)+樣式(CSS)+邏輯(JS)功能完備的結構單元，我們稱之為組件。

組件化≠模塊化。模塊化只是在文件層面上，對代碼或資源的拆分；而組件化是在設計層面上，對UI（用戶界面）的拆分。

其實，組件化更重要是一種分治思想。

Keep Simple. Everything can be a component.

頁面上所有的東西都是組件。頁面是個大型組件，可以拆成若干個中型組件，然后中型組件還可以再拆，拆成若干個小型組件，小型組件也可以再拆，直到拆成DOM元素為止。DOM元素可以看成是瀏覽器自身的組件，作為組件的基本單元。

傳統前端框架/類庫的思想是先組織DOM，然后把某些可復用的邏輯封裝成組件來操作DOM，是DOM優先；而組件化框架/類庫的思想是先來構思組件，然后用DOM這種基本單元結合相應邏輯來實現組件，是組件優先。這是兩者本質的區別。

其次，組件化實際上是一種按照模板(HTML)+樣式(CSS)+邏輯(JS)三位一體的形式對面向對象的進一步抽象。

所以我們除了封裝組件本身，還要合理處理組件之間的關系，比如 （邏輯）繼承、（樣式）擴展、（模板）嵌套和包含等，這些關系都可以歸為依賴。

目前市面上的組件化框架很多，主要的有Vue、React、Angular。Vue文檔中的對比其他框架一文已經講得很詳細了。

規范化

規范化其實是工程化中很重要的一個部分，項目初期規范制定的好壞會直接影響到后期的開發質量。

比如：

• 目錄結構的制定

  目錄結構的合理設定，能為項目帶來很多優點：

  • 有助於提高項目的邏輯結構合理性；
  • 對應擴展和合作；
  • 方便資源的統一定位管理。

• 編碼規范

  制定一套良好的編碼規范可以增強團隊開發協作、提高代碼質量。
  推薦參考凹凸實驗室打造的前端代碼規范。

  編碼規范包括

  • HTML規范。

    基於 W3C、蘋果開發者 等官方文檔，並結合團隊業務和開發過程中總結的規范約定，讓頁面HTML代碼更具語義性。

  • CSS規范。

    統一規范團隊 CSS 代碼書寫風格和使用 CSS 預編譯語言語法風格，提供常用媒體查詢語句和瀏覽器私有屬性引用，並從業務層面統一規范常用模塊的引用。

  • JS規范。

    統一規范團隊 CSS 代碼書寫風格和使用 CSS 預編譯語言語法風格，提供常用媒體查詢語句和瀏覽器私有屬性引用，並從業務層面統一規范常用模塊的引用。

  • 圖片規范。

    了解各種圖片格式特性，根據特性制定圖片規范，包括但不限於圖片的質量約定、圖片引入方式、圖片合並處理等，旨在從圖片層面優化頁面性能。

  • 命名規范。

    從 目錄、圖片、HTML/CSS文件、ClassName 的命名等層面約定規范團隊的命名習慣，增強團隊代碼的可讀性。

• 前后端接口規范

  “基於 Ajax 帶來的 SPA 時代”，這種模式下，前后端的分工非常清晰，前后端的關鍵協作點是 Ajax 接口，引發一個重要問題：前后端的對接界面雙方卻關注甚少，沒有任何接口約定規范情況下各自擼起袖子就是干，導致我們在產品項目開發過程中，前后端的接口聯調對接工作量占比在30%-50%左右，甚至會更高。往往前后端接口聯調對接及系統間的聯調對接都是整個產品項目研發的軟肋。

  接口規范主要初衷就是規范約定先行，盡量避免溝通聯調產生的不必要的問題，讓大家身心愉快地專注於各自擅長的領域。

  那么，對於這一SPA階段，前后端分離有幾個重要的關注挑戰：

  • 職責分離

    1. 前后端僅僅通過異步接口(AJAX/JSONP)來編程；
    2. 前后端都各自有自己的開發流程，構建工具，測試集合；
    3. 關注點分離，前后端變得相對獨立並松耦合。

    后端	前端
    提供數據	接收數據，返回數據
    處理業務邏輯	處理渲染邏輯

  • 規范原則

    1. 接口返回數據即顯示，前端僅做渲染邏輯處理；
    2. 渲染邏輯禁止跨多個接口調用；
    3. 前端關注交互、渲染邏輯，盡量避免業務邏輯處理的出現；
    4. 請求響應傳輸數據格式：JSON，JSON數據盡量簡單輕量，避免多級JSON的出現；

  • 響應格式

    1. 響應基本格式及處理狀態值的規范。
       • 基本響應格式
       • 列表響應格式
    2. 特殊內容
       • 下拉框、復選框、單選框統一由后端邏輯判定選中返回給前端展示；
       • 關於Boolean類型，JSON數據傳輸中一律使用1/0來標示，1為是/True，0為否/False
       • 關於日期類型，JSON數據傳輸中一律使用字符串，具體日期格式因業務而定；

• 文檔規范

• 組件管理

• git分支管理

• commit描述規范

• 視覺圖標規范

• ...

自動化

前端工程化的很多臟活累活都應該交給自動化工具來完成。需要秉持的一個理念是:

任何簡單機械的重復勞動都應該讓機器去完成。

• 圖標合並

• 持續繼承

• 自動化構建

• 自動化部署

• 自動化測試