工程化 經歷的 4 個階段

 連接

 工程化實踐 葉小釵

架構管理那些轉型的事情

 

大型網站工程與性能優化

初級階段， 選用什麼庫| 框架 才能 適合如今公司業務， 在現有成員技術能力基礎上能作到快速開發， 迭代

基礎庫 動畫 animate.css 數據操做 underscore.js dom操做 jquery 字體圖片 font Awesome

頁面佈局 bootstrap

框架 react vue angular avalon

合理的技術選型， 積累最適合的工具鏈， 能大大提升開發效率

中級階段：

簡單構件化 包括 css js 壓縮代碼 合併代碼， 代碼校驗等， 利用gulp grunt等

壓縮 合併 後能很大程度提升js 加載速度，

通過構建後提升性能仍是有很大幫助

高級階段：

利用 cmd amd 把複雜的代碼模塊化，

通過模塊化後， 能大大提升維護效率， 特別是多人開發的依賴管理問題， 模塊的複用等

最終階段：

組件化， 資源管理

解決 按需加載， 文件指紋， 多狀態， 不一樣的網絡環境， 不一樣的這段

前面階段是 模塊的分治， 但模塊太廣， 這個頁面能夠是模塊， 一個方法也能夠是模塊

而UI頁面一樣須要分治， 才能實現UI組件的複用， 實現組件的互相組合， 從而能夠應付各類需求的複雜變化

並且每一個組件在同一個目錄， 各類資源能夠就近維護， 讓開發變得更加集聚， 方便， 這樣也方便替換， 和刪除

就近維護是最有價值的， 現在 react vue都採用這種方式， 這樣有利於分工開發，

也有利於維護， 修改後不至於影響其餘組件功能

如： header 頭部導航 bill（開發者）

tab tab切換 馬化騰

list 新聞列表 李彥宏

footer 頁腳 馬雲

能夠看到， 他們4個能夠並行開發， 能夠支持多個成員 ， 甚至多個團隊共同維護一個大型站點


前期須要抽取一些底層模塊， 以及一些公共的UI組件， 好比分頁 ， 上傳， 日期等經常使用的組件

組件化作好以後， 須要 智能的靜態資源管理,  作好【增量】 加載

如何加載不一樣的組件， 現在有 webpack 能夠加載任何靜態資源， 好比圖片 css js html等， 實現了不一樣的頁面【增
量】 加載不一樣的組件資源, 同時也支持 延遲加載， 預加載等策略

隨着 瀏覽器緩存，利用 更新 共享 非覆蓋發佈等方案， 出現 BingRender BigPipe Quick PageCache等技術

這些雖然解決了各類資源等組合加載問題， 但對高複雜狀態的管理， 仍是還不夠智能

好比 1w+的靜態資源， 每一個資源須要生成 100 + 的語言

每一個資源針對不一樣的 瀏覽器終端 須要生成 5 + 的版本

須要針對不一樣寬帶的用戶 作成 3 種不一樣 的打包方式

須要對一些用戶推出 小批次的產品新功能體驗

而且 靜態資源的壓縮 和 非壓縮狀態能夠切換， 用於調試 和 定位線上問題

3g 網絡 + 新功能1 + 英文 + safari + pc端 + 多頁面 + 後端渲染 + 皮膚1

4g網絡 + 中文 + ios + 前端渲染 + 皮膚2

wifi + 韓文 + ie6/7 + 新功能2

這樣組合後， 狀態就變的很是多， 也很是複雜

解決這種問題， 須要掃描整個靜態資源， 組件， => 生成一個靜態資源表

而後有一個資源管理框架 經過查表來提供接口 加載各類資源， 去掉傳統的script link

靜態資源表來記錄 每一個資源 模塊的路徑和 依賴的模塊

{
"a.js": {
"url": "/static/js/a.5f100fa.js",
"dep": [ "b.js", "a.css" ]
},
"a.css": {
"url": "/static/css/a.63cf374.css",
"dep": [ "button.css" ]
},
"b.js": {
"url": "/static/js/b.97193bf.js"
},
"button.css": {
"url": "/static/css/button.de33108.js"
}
}

加載框架能夠利用各類性能優化算法來加載資源了 ，由於有了資源表，

咱們能夠很方便的控制資源加載，經過各類手段在運行時計算頁面的資源使用狀況，從而得到最佳加載性能

好比使用最多的優先加載， 經過日誌來監控， 甚至自動優化

 

框架具備很大的靈活性，並且不那麼黑盒，採用【框架】實現資源管理相比 【構建】更容易調試、定位和升級變動

就好像面向對象 和 面向過程那樣

https://blog.coding.net/blog/frontend-engineering