前端工程化知識要點回顧&思考

原文：https://github.com/kuitos/kui...

編程技術及生態發展的三個階段

• 最初的時候人們忙着補全各類API，表明着他們擁有的東西還很匱乏，須要在語言跟基礎設施上繼續完善

• 而後就開始各類模式，標誌他們作的東西逐漸變大變複雜，須要更好的組織了

• 而後就是各種分層MVC，MVP，MVVM之類，可視化開發，自動化測試，團隊協同系統等等，說明重視生產效率了，也就是所謂工程化

前端工程是軟件工程的一個子類別

軟件工程是一門研究用工程化方法構建和維護有效的、實用的和高質量的軟件的學科。

前端是一種GUI軟件

從本質上講，全部Web應用都是一種運行在網頁瀏覽器中的軟件，這些軟件的圖形用戶界面（Graphical User Interface，簡稱GUI）即爲前端。

前端又不一樣於傳統的客戶端軟件／後端，由於前端應用具有「免安裝」、「增量安裝」等特性。也「得益」於這些特性，前端應用會遭遇客戶端應用不可能碰到的資源管理問題，這也是前端最容易引發工程問題的點。

一個符合工程化要求的軟件系統(前端)須要包含的要素

1. 開發規範

2. 模塊化開發

3. 組件化開發

4. 組件倉庫

5. 性能優化

6. 項目部署

7. 開發流程

8. 開發工具

1-3是技術業務相關的開發需求，4是技術沉澱及共享需求，5-8是工程優化需求

大部分時候咱們談的「工程化」其實只是「工具化」。

每個單獨的點或許都比較容易實現，可是把這8條串聯起來則是一個很大的挑戰，並且這8個點相互之間又互有聯繫

• 模塊化開發涉及到性能優化，對構建工具備必定的配套實現要求，同時也會影響開發規範的制定

• 組件化開發應該基於模塊化框架來加載其餘依賴的組件，若是組件化框架自帶模塊管理功能，那麼就可能致使工程的性能優化實現困難（咱們能夠直接使用ES6的module語法及loader）

• 組件庫應該與組件化開發配套，組件倉庫中的組件應該按照相同的標準實現

• 開發規範工具必須容易實現，若是部署上有特殊要求，工具是否能很容易的作出調整而不是修改規範。

• 工具是否能提供接入公司已有流程的接口，是否能與公司的ci工具相互融合

爲何都說前端目前正遭遇史無前例的工程問題

1. 前端在第一、2階段耗費了十多年的時間，而後近幾年才井噴式的爆發

2. 因爲整個生態的發展緩慢、門欄低、構建應用成本低，前端開發長時間停留在刀耕火種、茹毛飲血的階段

3. 之前大部分前端工做都是切頁面加特效，還不能算得上一個真正意義上的webapp，天然不多有公司能遭遇到工程化問題

4. 前端不一樣於 客戶端／後端 的特性(好比增量安裝)，致使遭遇的工程會很特殊，很難直接從別的領域套用已有的解決方案

5. 咱們本身徹底意識不到那是問題?

工程化到底要解決哪些問題

1. 合理的開發流程及開發規範，包括代碼規範、模塊化組件化規範(分治)等（提升生產力）

2. 一套自動化代碼質量檢測方案（提升系統可靠性）

3. 一套自動化及高度適應性的項目 發佈／部署 方案（提升系統的伸縮性及靈活性）

4. 極致的性能優化，包括減小冗餘的接口請求及資源請求、提升緩存命中率等，簡言之就是站點的打開及運行速度（更好的用戶體驗）

舉三個案例：

1. 最基本的資源合併，咱們應該採起哪一種策略？所有打包成一個仍是分開打包？如何最高效的利用緩存？如何在下降請求數的同時提升緩存利用率？移動終端又應該採起哪一種策略？

2. 發佈的時候咱們究竟是應該先部署頁面仍是靜態資源？如何實現平滑升級？若是我還想玩個灰度發佈呢？

3. 若是採用模塊化按需加載的方式開發，每次發佈資源文件都會有不一樣的md5值，如何在不影響開發體驗的前提下確保能引用到正確的模塊？

相關工具？

1. 構建工具 gulp
   task-based的方式使得gulp沒法(難以)處理資源嵌套的遞歸場景。如 a.js -> b.scss -> md5(d.img) -> md5(b.scss) -> md5(a.js)

2. 基於 資源表＋資源管理框架 策略的 fis
   其實已經能處理大部分場景了，可是侵入式代碼實在是沒法接受。由於它是一個框架。

3. 靜態分析工具 webpack
   webpack依賴其可配置的loader使其擁有強大的打包能力，可是依然沒法實現動態按需加載的需求。相似：

   if(browser){
       require('browser.js');
   } else {
       require('node.js');
   }

出路

ES6 Module ＋ ES6 Module Loader ＋ HTTP2.0 ＋ Others

ES6 Module提供了一個原生的模塊化語法，ES6 Module Loader則能提供一個原生的模塊加載器。對於前端工程而言，資源管理是最核心的問題，而資源管理中加載又是重點更是難點。

但是ES6 Module Loader從ES6草案中移除了如今由WHATWG組織還在維護制定標準，pending狀態。。
如今有一個基於這個草案實現的api polyfill Module Loader。但是你不是規範我這種教條主義者是不會用的?

總結

前端工程化相關問題是隨着前端的發展愈來愈受到重視的問題，一套好的工程化解決方案能在提升開發效率(包括代碼編寫的溫馨度及多人協做)的同時確保整個系統的伸縮性(各類不一樣的部署環境)及健壯性(安全)，同時在性能上又能有一個很優異的表現(主要上各類緩存策略加載策略等)，並且這套方案又應該是對工程師無感知(或感知很小)趨於自動化的一套方案。總之，要達到這個目的前端工程化還有很長一段路要走。

拓展閱讀

1. 國內工程化第一人系列文章 https://github.com/fouber/blo...

2. 大公司是如何部署前端代碼的

3. 相關工具

   • 百度：fis （資源表＋資源管理框架 策略）

   • UC：scrat

   • 騰訊：mtjs （能夠實現字節增量發佈）