## 前言 在大前端的趨勢下，原來的切圖仔或者說前端工程師已經不能承載實際需要，在開發以及調試中，我們需要一系列的方案來讓我們的項目變得優化，規范，可配置等。本文就這方面做簡單分析，并列出了一系列的解決方案， ## 了解我們所處的階段 前端從無到有，從簡單到復雜，從手動到配置，從融合到后端到主導用戶應用，不斷的對前端的工程化提出了新的概念和挑戰，而在這一系列的工具或者方法中，簡單分出以下幾個階段。 ### stage1：庫、框架的選型  前端工程建設的第一項任務就是根據項目特征進行技術選型。 基本上現在沒有人完全從0開始做網站，最少都會選下jquery，而React/Angularjs等框架橫空出世，也讓前端對頁面交互、路由控制等有了更多的話語權。 ### stage2：簡單構建  完成項目之后，一般我們都需要對項目中引用的文件進行簡單的優化，包括校驗、壓縮、合并等，而目前市場上提供的構建工具有grunt,gulp,fis以及webpack等。 而市場上目前能做到這個階段在業界來說已然超出平均水平，屬于“具備較高工程化程度”的團隊了，查看中國中小企業的網頁源代碼，能做到最基本的JS/CSS壓縮的Web應用都已跨入標準互聯網公司行列，不難理解為什么很多前端團隊對于前端工程構建的認知還僅停留在“壓縮、校驗、合并”這種程度。 但是我們必須將自己的前端工作做到行業的前列，所以當下我們在僅僅停留在第一階段的時候，需要快速進入第二階段，邁向第三階段。 ### stage3:JS/CSS模塊化開發 分而治之是軟件工程中的重要思想，是復雜系統開發和維護的基石，這點放在前端開發中同樣適用。在解決了基本開發效率運行效率問題之后，前端團隊開始思考維護效率，模塊化是目前前端最流行的分治手段。 很多人覺得模塊化開發的工程意義是復用，我不太認可這種看法，在我看來，模塊化開發的最大價值應該是分治，只有根據自己的業務需要不斷的整合并且開出新的分之，并且分別維護才可以讓業務或者技術更加純熟。而簡單的模塊復用是不足以應對復雜，多變的需求的。 分治的本質就是針對一對代碼，一個文件，我們都應該將其定義為模塊。JS模塊化方案很多，AMD/CommonJS/UMD/ES6 Module等，對應的框架和工具也有很多；CSS模塊化開發基本都是在less、sass、stylus等預處理器的import/mixin特性支持下實現的（本博客系統就是基于stylus實現）。 ### stage4：工程化問題的爆發 首先要認識到，前端是一種技術問題較少、工程問題較多的軟件開發領域。很多人覺得前端門檻低，但是真到這個行業發現有若干的坑需要踩，沒有寫幾行代碼那樣簡單。那可能遇到什么問題呢？ 1. 大體量：多功能、多頁面、多狀態、多系統； 2. 大規模：多人甚至多團隊合作開發； 3. 高性能：CDN部署、緩存控制、文件指紋、緩存復用、請求合并、按需加載、同步/異步加載、移動端首屏CSS內嵌、HTTP 2.0服務端資源推送。 ## 解決方案 如果要解決上面的問題，我覺得應該從以下幾個方面入手，以后也將重點就以下幾個方面以及項目中的具體問題做拓展。 ### 整體規范 * 設計規范 設計規范是一個前端工程界面部分規范不可或缺的部分，如果設計以及產品不能按照一定的規范執行，那么最終的產品體驗以及工程化產物也是復用度很低，不適用于大多數項目的。所以要求公司對所有的公司產品從原型設計到設計稿設計，有整套的設計規范，去除不必要的自由發揮。 * 前端代碼規范 從源頭開始制定代碼規范，所有的代碼符合這一規范，目前制定了包括html\css\js\less在內的代碼規范。針對前端項目中遇到的問題，也將統一制定解決方案。比如web視頻解決方案，時間控件解決方案，二維碼解決方案等。 * 構建規范 從構建工具開始，每一個細節告訴開發成員應該如何操作，怎樣才是規范的，提供完整詳細的教程文檔以及輔導體制。減少使用不必要的，不規范的代碼壓縮、驗證操作以及不規范的文檔結構。 ### 組件化開發 前端作為一種GUI軟件，光有JS/CSS的模塊化還不夠，對于UI組件的分治也有著同樣迫切的需求。為了更好的實現代碼復用，提高工作效率，我強烈建議在項目團隊中應該有一定比例的人負責ui組件的開發。而另一部分人是負責使用以及維護，并不斷提出優化建議。組件化開發的圖示應該是下圖所示：  提到組件開發，不僅僅是前端項目可以用，在很多以后臺為主導的項目，組件的思路也可以得到靈活的應用。由此可見，以后我們應該更靈活的開發樣式，腳本等。在提供一個大而全的框架的同時，也提供讓用戶可以根據自己的一個小需求，僅僅引入一個小的組件。  如果有以上的工程概念，那么為了實現優化，我們需要針對不同的組件指定開發者，并在一個開源項目上讓大家的組件都是可見的。并且可以無縫的融合到一起，如果要做到這一點，就必須共同遵循同一套規則。其中版本管理的建議用git，而公司內部的gitlab已經為我們提供了便利條件。不同人員分工的圖示如下：  ### 不同維度 就項目而言，一個組件是遠遠不夠的，在實際的開發當中，我們的使用是分很多種情況的。 有的時候需要根據自己的業務，有的時候需要根據自己的組件，而有時候又是僅僅需要某些頁面。所以針對不同的情況，我們可以參考以下的圖示，同時需要了解到這種情況是允許存在的。  如果放到一個項目中，可能就是下圖所示的結構。   針對中小型項目，建議的文檔結構，也是我們目前正在逐步普及的目錄結構。最常見的頁面+less組件維度。  ### 靜態資源管理 如果說前端對客戶端的優點，目前的界面以及交互式肯定比不上的，但是前端的gui界面沒有安裝的概念，而安裝的概念就是把客戶端里需要的ui全部本地存儲一份。那如果前端在第一次需要的時候就加載全部文件，顯然也是不合理的，所以規范的web應用也不會這么做。一般的做法是針對需求做增量更新，最常見的例子就是12306每次的web升級包，雖然它交互并不好。 由“增量”原則引申出的前端優化技巧幾乎成為了性能優化的核心，有加載相關的按需加載、延遲加載、預加載、請求合并等策略；有緩存相關的瀏覽器緩存利用，緩存更新、緩存共享、非覆蓋式發布等方案；還有復雜的BigRender、BigPipe、Quickling、PageCache等技術。這些優化方案無不圍繞著如何將增量原則做到極致而展開。 資源管理的藍圖如下：其中構建工具的部分是通用的，具體選用的時候是針對性的。  ## 工程化實踐 ### 技術選型 * 規范：已制定的相關文檔 * 版本管理： git，嚴格按照版本管理+分之管理進行（支持多分之，bug分之，功能分之等） * 開源項目倉庫：github,gitlab * 開發目錄： src+dist+lib+test(測試)+ node_modules +bower_components * 前端構建工具： gulp +gulp基本插件（gulp-less等） * 組件開發工具：less * 前端頁面模板引擎：tmod，artTemplate * 前端框架選型：jq+boot+jq插件 * 前端ide ：hbuilder+emmet * 開發環境：chrome+devTool +模擬器 * 包管理器：npm -package.json（npm init ,npm (un)publish,npm install） * 依賴資源加載：bower * 同步調試：browserSync 多終端同步調試工具 * 前端依賴模塊（瀏覽器環境）：requirejs (seajs) * js模塊化： cmd,amd模塊規范 * 前端服務器：nodejs ### 技術創新部分 * cnpm企業倉庫 支持內網npm倉庫，比npm請求更快。支持企業內部的npm模塊發布與使用。 * gulp項目構建 支持常見的插件使用，支持gulp的構建實踐，實現了開發與生產目錄的分離，切實的優化了web項目。 * less組件命名規范化 基于模塊化之后的深度理解，著重使用less的相關規則，將樣式拆分為不同分類，還有不同組件，將css的技術解決方案、兼容方案融合到組件當中。 * npm模塊的定義與發布 研究了npm js模塊的發布機制，可以自行發布模塊，供內部員工使用。 * 調試開發（browserSync） 摒棄手動多端測試，實現多終端自動測試，開發同步修改。 * 代碼規范 針對公司全體前端制定代碼規范，提供前端頁面初始化模板。 * 多環境集成git 包括git bash,toriseGit,hb,ws,eclipse多軟件集成，讓git版本管理使用便攜。同時深度調研git版本管理命令行，提供git版本管理入門123系列教程，為公司提供技術支持。 * nrm無痛切換多源 可以讓你在內網，外網多環境下使用npm命令行 * npm加載請求機制 可以根據自己的需求，靈活選擇緩存安裝還是本地代理安裝還是企業內網安裝 ## 其他 本文部分內容參考以下文檔，表示真心的感謝！ * fouber：[前端工程化基礎篇]