在回答這個問題以前,我先回顧一下前端的歷史。大約78年前,前端工程師還不是一個受人重視的職位,平常工做也就是切個圖,使用JQuery寫個腳本,從某種意義上講,只是後端的附屬物。最近幾年,尤爲是在nodejs出現以後,前端愈來愈受到重視,甚至已經開始搶佔了後端的市場。這同時也帶來了一個問題,前端的規模愈來愈大,已經上升到了工程學的問題,如何提升前端工程師的開發效率變得很是重要。這就是前端工程化所要解決的問題。前端工程化是根據業務特色,將前端開發流程規範化,標準化,它包括了開發流程,技術選型,代碼規範,構建發佈等,用於提高前端工程師的開發效率和代碼質量。css
回答這個問題應該從一個前端工程的生命週期提及,在這個生命週期中任何的優化都應屬於前端工程化的範疇。前端
我在上一家公司工做時,前端的架構比較簡單,典型的angular工程加上gulp去進行構建。當你手裏有一把錘子時,你看什麼都是釘子。這形成了很長一段時間內對前端工程化的理解就是使用gulp等構建工具。爲何gulp不能徹底算是前端工程化解決方案呢?首先先看看gulp幫咱們解決了哪些東西和沒有解決哪些東西。一般狀況下對gulp的使用會藉助gulp的各類插件,以一種工做流的形式對代碼進行檢查,執行壓縮,移動到相關目錄下,發佈到git倉庫等。從某種意義上來講,gulp確實幫助提升了開發的效率,可是它所作的東西頗有限,它只是幫咱們進行了構建,並且構建方案須要咱們本身去寫,自由度相對較大,也沒有解決開發目錄約束,代碼規範等一系列問題。node
一個符合前端工程化要求的方案應該包含如下要素:git
業界中比較優秀的方案有:gulp
因爲對第一種和第三種方案不太熟悉,我主要談談scrat是怎麼解決前端工程化中的各類問題。
scrat包括兩部分: 構建方案和前端模塊化框架scrat.js。構建方案首先從開發目錄結構對工程進行了約束,目錄結構大體以下:
├─ component_modules (生態模塊)
├─ components (工程模塊)
├─ views (非模塊化資源)
├─ ...
它將靜態資源分爲兩種:
模塊化資源: 具備獨立性的模塊所對應的靜態資源。每一個獨立的模塊將本身所須要的js、css、模板、圖片等資源放在一塊兒維護,使得模塊具有獨立性,引用模塊的js便可。
非模塊化資源: 雖然在模塊化開發體系內,應該一切皆模塊,但總有不該該成爲模塊的資源,好比入口頁面、模塊化框架、頁面啓動器等。
它定義本身的模塊化系統,認爲模塊是可組合,可分解和更換的單元。工程師能夠像搭積木同樣開發和維護系統,經過組裝獲得一個完整的系統。scrat.js做爲模塊化開發框架,實現了js/css依賴管理,請求合併,按需加載,本地緩存等功能,達到效果優化。具體使用方案請參考其官網。後端
我能想到的還有如下這些:
git工做流 - 如何提交代碼?
Node中間層 - 用於渲染一部分模板和路由等。
CI/CD - 主要利用git hooks通知CI,執行對應的腳本(如gitlab)。
監控 - 前端監控主要分爲性能監控和業務監控,它應支持自由配置各類報表和一系列報警規則。前端工程化