野狗君說 | 前端工程師怎么了??
編程技術(shù)及生態(tài)發(fā)展的三個階段
------------------------------
最初的時候人們忙著補全各種API，代表著他們擁有的東西還很匱乏，需要在語言跟基礎(chǔ)設(shè)施上繼續(xù)完善
然后就開始各種模式，標(biāo)志他們做的東西逐漸變大變復(fù)雜，需要更好的組織了
然后就是各類分層MVC，MVP，MVVM之類，可視化開發(fā)，自動化測試，團(tuán)隊協(xié)同系統(tǒng)等等，說明重視生產(chǎn)效率了，也就是所謂工程化
前端工程是軟件工程的一個子類別
------------------------------
軟件工程是一門研究用工程化方法構(gòu)建和維護(hù)有效的、實用的和高質(zhì)量的軟件的學(xué)科。
前端是一種GUI軟件
------------------------------
從本質(zhì)上講，所有Web應(yīng)用都是一種運行在網(wǎng)頁瀏覽器中的軟件，這些軟件的圖形用戶界面（Graphical User Interface，簡稱GUI）即為前端。
前端又不同于傳統(tǒng)的客戶端軟件／后端，因為前端應(yīng)用具備“免安裝”、“增量安裝”等特性。也“得益”于這些特性，前端應(yīng)用會遭遇客戶端應(yīng)用不可能碰到的資源管理問題，這也是前端最容易引起工程問題的點。
一個符合工程化要求的軟件系統(tǒng)(前端)需要包含的要素
------------------------------
開發(fā)規(guī)范
模塊化開發(fā)
組件化開發(fā)
組件倉庫
性能優(yōu)化
項目部署
開發(fā)流程
開發(fā)工具
1-3是技術(shù)業(yè)務(wù)相關(guān)的開發(fā)需求，4是技術(shù)沉淀及共享需求，5-8是工程優(yōu)化需求
大部分時候我們談的“工程化”其實只是“工具化”。
每一個單獨的點或許都比較容易實現(xiàn)，但是把這8條串聯(lián)起來則是一個很大的挑戰(zhàn)，而且這8個點相互之間又互有聯(lián)系
模塊化開發(fā)涉及到性能優(yōu)化，對構(gòu)建工具有一定的配套實現(xiàn)要求，同時也會影響開發(fā)規(guī)范的制定
組件化開發(fā)應(yīng)該基于模塊化框架來加載其他依賴的組件，如果組件化框架自帶模塊管理功能，那么就可能導(dǎo)致工程的性能優(yōu)化實現(xiàn)困難（我們可以直接使用ES6的module語法及l(fā)oader）
組件庫應(yīng)該與組件化開發(fā)配套，組件倉庫中的組件應(yīng)該按照相同的標(biāo)準(zhǔn)實現(xiàn)
開發(fā)規(guī)范工具必須容易實現(xiàn)，如果部署上有特殊要求，工具是否能很容易的做出調(diào)整而不是修改規(guī)范。
工具是否能提供接入公司已有流程的接口，是否能與公司的ci工具相互融合
為什么都說前端目前正遭遇前所未有的工程問題
------------------------------
前端在第1、2階段耗費了十多年的時間，然后近幾年才井噴式的爆發(fā)
由于整個生態(tài)的發(fā)展緩慢、門欄低、構(gòu)建應(yīng)用成本低，前端開發(fā)長時間停留在刀耕火種、茹毛飲血的階段
以前大部分前端工作都是切頁面加特效，還不能算得上一個真正意義上的webapp，自然很少有公司能遭遇到工程化問題
前端不同于 客戶端／后端 的特性(比如增量安裝)，導(dǎo)致遭遇的工程會很特殊，很難直接從別的領(lǐng)域套用已有的解決方案
我們自己完全意識不到那是問題??
工程化到底要解決哪些問題
------------------------------
合理的開發(fā)流程及開發(fā)規(guī)范，包括代碼規(guī)范、模塊化組件化規(guī)范(分治)等（提高生產(chǎn)力）
一套自動化代碼質(zhì)量檢測方案（提高系統(tǒng)可靠性）
一套自動化及高度適應(yīng)性的項目 發(fā)布／部署 方案（提高系統(tǒng)的伸縮性及靈活性）
極致的性能優(yōu)化，包括減少冗余的接口請求及資源請求、提高緩存命中率等，簡言之就是站點的打開及運行速度（更好的用戶體驗）
舉三個案例：
最基本的資源合并，我們應(yīng)該采取哪種策略？全部打包成一個還是分開打包？如何最高效的利用緩存？如何在降低請求數(shù)的同時提高緩存利用率？移動終端又應(yīng)該采取哪種策略？
發(fā)布的時候我們到底是應(yīng)該先部署頁面還是靜態(tài)資源？如何實現(xiàn)平滑升級？如果我還想玩?zhèn)€灰度發(fā)布呢？
如果采用模塊化按需加載的方式開發(fā)，每次發(fā)布資源文件都會有不同的md5值，如何在不影響開發(fā)體驗的前提下確保能引用到正確的模塊？
相關(guān)工具？
------------------------------
構(gòu)建工具 gulp：task-based的方式使得gulp無法(難以)處理資源嵌套的遞歸場景。如 a.js -> b.scss -> md5(d.img) -> md5(b.scss) -> md5(a.js)
基于 資源表＋資源管理框架 策略的fis：其實已經(jīng)能處理大部分場景了，但是侵入式代碼實在是無法接受。因為它是一個框架。
靜態(tài)分析工具 webpack：webpack依賴其可配置的loader使其擁有強大的打包能力，但是依然無法實現(xiàn)動態(tài)按需加載的需求。類似：
if(browser){
require('browser.js');
} else {
require('node.js');
}
出路
------------------------------
ES6 Module ＋ ES6 Module Loader ＋ HTTP/2.0 ＋ Others
ES6 Module提供了一個原生的模塊化語法，ES6 Module Loader則能提供一個原生的模塊加載器。對于前端工程而言，資源管理是最核心的問題，而資源管理中加載又是重點更是難點。
可是ES6 Module Loader從ES6草案中移除了現(xiàn)在由WHATWG組織還在維護(hù)制定標(biāo)準(zhǔn)，pending狀態(tài)。。
現(xiàn)在有一個基于這個草案實現(xiàn)的api polyfill Module Loader?？墒悄悴皇且?guī)范我這種教條主義者是不會用的??
HTTP/2.0是HTTP/1.1的升級版(非革命版，前身是Google的SPDY協(xié)議)，2015年5月以RFC 7540正式發(fā)表，新增了幾個關(guān)鍵特性：
多路復(fù)用
HEAD壓縮
服務(wù)端推送
其中多路復(fù)用是對前端感知最明顯的特性，基于此特性，HTTP/2.0時代需要淘汰的優(yōu)化方式：
域名散列（突破單一域名請求連接數(shù)限制）
資源合并（多路復(fù)用帶來了跟資源合并同樣的效果，相反資源會造成的緩存利用率降低）
資源內(nèi)聯(lián)（server push）
ps:目前的各種bundle方案(如browserify&webpack)可能會在http2.0時代被淘汰(替代)，有測試表明在http2.0環(huán)境下多文件請求會比單請求大文件更快。移動終端的意義更大，你無法想象移動端創(chuàng)建一個連接開銷有多大。。多路復(fù)用才是未來！
總結(jié)
------------------------------
前端工程化相關(guān)問題是隨之前端的發(fā)展越來越受到重視的問題，一套好的工程化解決方案能在提高開發(fā)效率(包括代碼編寫的舒適度及多人協(xié)作)的同時確保整個系統(tǒng)的伸縮性(各種不同的部署環(huán)境)及健壯性(安全)，同時在性能上又能有一個很優(yōu)異的表現(xiàn)(主要上各種緩存策略加載策略等)，而且這套方案又應(yīng)該是對工程師無感知(或感知很小)趨于自動化的一套方案?？傊_(dá)到這個目的前端工程化還有很長一段路要走。
↓戳這里，了解野狗！
聯(lián)系客服
