前端工程化

前端架構：

1.前端工程化

web應用複雜度的增長，特別是單頁面應用的風靡。組件化，工程化，自動化成了前端發展的趨勢。或者說一線的互聯網公司就是這麼作的。
每一個前端團隊都在打造本身的前端開發體系，這一般是一個東拼西湊，逐漸磨合的過程，在技術發展突飛猛進的今天，這樣的過程真的是不可抽象和複製的麼？本文但願可以經過系統的拆解前端開發體系爲你們提供體系設計思路參考。

前端工程的3個階段


第一階段： 庫/框架選型


Animate.css 
jQuery 
vue.js 
underscore.js 
React.js 
Backbone.js 
Bootstarp 
zepto.js 
jade 
normalize.css 
compass 
Angular.js 
解決開發效率


第二階段： 簡單構建優化


選擇構建工具，對代碼進行壓縮，校驗，以後再以頁面爲單位進行簡單的資源合併。


第三階段： JS/CSS模塊化開發


解決維護效率 
js的模塊化方案 
ADM/CDM/UMD/ES6 Module


css的模塊化：less，sass。


第四階段: 前端是一個技術問題較少，工程問題較多的開發領域


當咱們要開發一款完整的Web應用時，前端將面臨更多的工程問題，好比： 
- 大致量：多功能、多頁面、多狀態、多系統； 
- 大規模：多人甚至多團隊合做開發； 
- 高性能：CDN部署、緩存控制、文件指紋、緩存複用、請求合併、按需加載、同步/異步加載、移動端首屏CSS內嵌、HTTP 2.0服務端資源推送。


組件化開發和資源管理


組件化開發： 
光有JS/CSS的模塊化還不夠，對於UI組件的分治也有着一樣迫切的需求
資源管理： 
根據「增量」的原則，咱們應該精心規劃每一個頁面的資源加載策略，使得用戶不管訪問哪一個頁面都能按需加載頁面所需資源，沒訪問過的無需加載，訪問過的能夠緩存複用，最終帶來流暢的應用體驗。
由增量原則引伸的前端優化技巧成爲了性能優化的核心: 
按需加載 
延遲加載 
預加載 
請求合併


瀏覽器的緩存


靜態資源管理系統 = 資源表 + 資源加載框架


前端模塊化框架肩負着模塊管理和資源加載2個重要的功能


webpack已經成爲了前端打包構建的主流。


開發框架則是造成了三國時代： 
React ， Vue， Ng


移動端也以混合開發爲主的方式，Native嵌入了Webview頁面。


SPA依靠首次加載的Loading動畫，來掩蓋一些頁面加載性能的問題。


用戶驗證問題，怎麼來確認Native的用戶身份，是用原來Web網站經常使用的session仍是使用Native比較經常使用的token，可是無論用哪一種，都須要Native幫忙來注入標識。


前端業務重量化，場景多樣化。 
將來的趨勢： 組件化。


美團的工程化


關於前端工程化，我看了美團團隊的分享： 
他們分享的前端化的實踐總結： 
1. 前端開發要自成體系，包括構建、部署及運維，再也不和後端項目耦合，後端經過RESTful接口提供服務。 
2. 避免重量級的框架，沒有一個框架能夠知足全部的業務場景。 
3. 設計要分層，來應對需求和技術的變化。


前端工程化項目分爲3大模塊： 
1. Node服務，提供數據代理，路由，和服務器渲染，經過restful api和後端通訊。 
2. web應用開發，專一於web交互體驗。 
3. 前端運維：包含構建，測試，部署及監控等。


Node服務：用於實現先後端分離，核心功能是實現數據代理中轉，附帶url路由分發和服務端渲染功能。
Web應用開發：純粹的前端模塊，給予前端工程師極大的自由度進行技術選型，專一於Web交互體驗的開發。
前端運維：主要指前端項目構建和部署、工程質量（源碼質量檢查和測試等）及監控服務（日誌、性能等）等工做。
先後端分離： 
- 爲了先後端完全的分離，引入Node服務層。 
- 即在Node端經過HTTP請求獲得數據後，Web端再經過Ajax的方式從Node端間接獲取後端數據，Node服務起到「橋樑」的做用。 
- 路由分發 
- 服務器端渲染：Node服務端最後一個核心功能是渲染：輸出 HTML Shell和 JSON。輸出JSON字符串的用途是爲了瀏覽器端能以Ajax形式動態獲取數據，而輸出的HTML內容則是咱們Web應用的所需的HTML「殼子」。


這主要是SPA的快速發展，前端的用戶體驗大幅提高。


靜態資源與Node端銜接： 
- 前端靜態資源構建工做與Node服務相互分離，Node服務在開啓的過程當中會讀取前端構建生成的靜態資源映射表。 
- 靜態資源映射表的生成： 
- 預編譯：ES6語法轉義，css預編譯器處理，源碼質量審查，測試 
- 模塊依賴解析 
- 壓縮，靜態資源版本號


前端構建工具基本都提供靜態資源映射表生成插件，好比構建工具Webpack就存在插件assets-webpack-plugin來實現該功能。


鼓勵遵循下面幾條「約定」： 
- Ajax請求從Node端代理，而非具體後端服務。 
- 鼓勵將JavaScript、CSS、HTML視爲前端領域的「彙編」。 
- 重視前端頁面狀態管理，推薦的方案有Redux、vuex及MobX等。 
- 強調組件化，面向組件集開發。
項目的腳手架，來搭建項目的開發環境。


工程質量保證，在每次的commit，同個項目要求遵循同一套編碼規範，並採用ESLint等工具進行約束，對於一些複用性高的核心組件也強制要求寫測試。 
甚至是接入單獨的系統測試。


總結


前端工程化體系的引入，讓前端開發能和原生App應用項目開發同樣「自成體系」，脫離了對後端項目的依賴。基於「約定優於配置」、「按照約定寫代碼」的原則對Node層功能的設定可以下降溝通協調成本，構建、部署等工做的規範化，使前端技術人員的開發重點回歸到Web應用的交互體驗自己，迴歸到「純粹」的前端研發。

或許如今不少企業和團隊還沒有重視前端工程，或許前端工程在不少人眼裏還只是「構建工具」的代名詞，又或許將來前端領域的變革使得一切工程問題從根本上獲得解決。無論怎樣，我只是但願當下能認真的記錄本身在前端工程領域的所見所想，與正在經歷前端工程化改進，並被此過程困擾的同窗交流心得。

先說概念：前端工程化是使用軟件工程的技術和方法來進行前端項目的開發、維護和管理（曾經的前端開發可不是這樣的，否則爲何要說工程"化"呢？）。

 

"前端工程化"裏面的工程指軟件工程，和咱們通常說的工程是兩個徹底不一樣的概念。

• 工程是個很泛泛的概念，你甚至能夠認爲建了個 Git 倉庫就至關於新建了一個工程；
• 軟件工程的定義是："應用計算機科學理論和技術以及工程管理原則和方法，按預算和進度，實現知足用戶要求的軟件產品的定義、開發、和維護的工程或進行研究的學科"（GB/T11457-2006《信息技術 軟件工程術語》）。

不少時候，咱們的前端確實是個工程，但並非在以軟件工程的方式方法去對待它。

爲何會出現"前端工程化"這個概念？

• "這個活動頁面，給張圖切一下就好了嘛"；
• "這個管理後臺已經經過 XXX 腳手架生成了，頁面稍微改改就行"；
• ...

前端的開發工做在一些場景下被認爲只是平常的一項簡單工做，或只是某個項目的"附屬品"，並無被當作一個"軟件"而認真對待（不管是產品負責人仍是開發者）。

然而不管你如何對待它，也沒法否認前端是一種 GUI 軟件的事實，所以其也就必然遵循時間、質量、成本相互制約的特性。對於時間和成本的控制必然將致使最終產出傾向於出現"質量低"、"可維護性差"、"可用性差"等問題。

過去咱們以犧牲質量的方式換取時間和成本，如今趟了前輩們早已趟過的坑，而後發現仍是要從新審視"前端"這一軟件開發活動，而且使用軟件工程這套早已存在的體系去對前端項目進行管理。

 

 

 

目前來講，Web業務日益複雜化和多元化，前端開發已經由以WebPage模式爲主轉變爲以WebApp（eg:https://app.ft.com/）(httpshttps其實就是建構在SSL/TLS之上的 http協議，因此要比較https比http多用多少服務器資源，主要看SSL/TLS自己消耗多少服務器資源。)模式爲主了。如今隨便找個前端項目，都已經不是過去的拼個頁面+搞幾個jQuery插件就能完成的了。工程複雜了就會產生許多問題，好比：如何進行高效的多人協做？如何保證項目的可維護性？如何提升項目的開發質量？

前端工程化是前端架構中重要的一環，主要就是爲了解決上述大部分問題的。而前端工程本質上是軟件工程的一種，所以咱們應該從軟件工程的角度來研究前端工程。那麼前端工程化須要考慮哪些因素？本人總結經驗，認爲前端工程化主要應該從模塊化、組件化、規範化、自動化四個方面來思考，下面一一展開。## 模塊化簡單來講，模塊化就是將一個大文件拆分紅相互依賴的小文件，再進行統一的拼裝和加載。只有這樣，纔有多人協做的可能。### JS的模塊化在ES6以前，JavaScript一直沒有模塊系統，這對開發大型複雜的前端工程形成了巨大的障礙。對此社區制定了一些模塊加載方案，如CommonJS、AMD和CMD等，某些框架也會有本身模塊系統，好比Angular1.x。如今ES6已經在語言層面上規定了模塊系統，徹底能夠取代現有的CommonJS和AMD規範，並且使用起來至關簡潔，而且有靜態加載的特性。規範肯定了，而後就是模塊的打包和加載問題：1. 用Webpack+Babel將全部模塊打包成一個文件同步加載，也能夠打成多個chunk異步加載；2. 用SystemJS+Babel主要是分模塊異步加載；3. 用瀏覽器的<script type="module">加載目前Webpack遠比SystemJS流行。Safari已經支持用type="module"加載了。### CSS的模塊化雖然SASS、LESS、Stylus等預處理器實現了CSS的文件拆分，但沒有解決CSS模塊化的一個重要問題：選擇器的全局污染問題。按道理，一個模塊化的文件應該要隱藏內部做用域，只暴露少許接口給使用者。而按照目前預處理器的方式，導入一個CSS模塊後，已存在的樣式有被覆蓋的風險。雖然重寫樣式是CSS的一個優點，但這並不利於多人協做。爲了不全局選擇器的衝突，各廠都制定了本身的CSS命名風格：BEM風格；

 

Bootstrap風格；Semantic UI風格；咱們公司的NEC風格；...但這畢竟是弱約束。選擇器隨着項目的增加變得越多越複雜，而後項目組裏再來個新人帶入本身的風格，就更加混亂了。因此我很贊同這句話：與其費盡心思地告訴別人要遵照某種規則，以規避某種痛苦，倒不如從工具層面就消滅這種痛苦。從工具層面，社區又創造出Shadow DOM、CSS in JS和CSS Modules三種解決方案。Shadow DOM是WebComponents的標準。它能解決全局污染問題，但目前不少瀏覽器不兼容，對咱們來講還好久遠；CSS in JS是完全拋棄CSS，使用JS或JSON來寫樣式。這種方法很激進，不能利用現有的CSS技術，並且處理僞類等問題比較困難；CSS Modules仍然使用CSS，只是讓JS來管理依賴。它可以最大化地結合CSS生態和JS模塊化能力，目前來看是最好的解決方案。Vue的scoped style也算是一種。
### 資源的模塊化Webpack的強大之處不只僅在於它統一了JS的各類模塊系統，取代了Browserify、RequireJS、SeaJS的工做。更重要的是它的萬能模塊加載理念，即全部的資源均可以且也應該模塊化。資源模塊化後，有三個好處：依賴關係單一化。全部CSS和圖片等資源的依賴關係統一走JS路線，無需額外處理CSS預處理器的依賴關係，也不需處理代碼遷移時的圖片合併、字體圖片等路徑問題；資源處理集成化。如今能夠用loader對各類資源作各類事情，好比複雜的vue-loader等等。項目結構清晰化。使用Webpack後，你的項目結構總能夠表示成這樣的函數：
dest = webpack(src, config)## 組件化首先，組件化≠模塊化。好多人對這兩個概念有些混淆。模塊化只是在文件層面上，對代碼或資源的拆分；而組件化是在設計層面上，對UI（用戶界面）的拆分。從UI拆分下來的每一個包含模板(HTML)+樣式(CSS)+邏輯(JS)功能完備的結構單元，咱們稱之爲組件。其實，組件化更重要的是一種分治思想。Keep Simple. Everything can be a component.
這句話就是說頁面上全部的東西都是組件。頁面是個大型組件，能夠拆成若干個中型組件，而後中型組件還能夠再拆，拆成若干個小型組件，小型組件也能夠再拆，直到拆成DOM元素爲止。DOM元素能夠當作是瀏覽器自身的組件，做爲組件的基本單元。傳統前端框架/類庫的思想是先組織DOM，而後把某些可複用的邏輯封裝成組件來操做DOM，是DOM優先；而組件化框架/類庫的思想是先來構思組件，而後用DOM這種基本單元結合相應邏輯來實現組件，是組件優先。這是二者本質的區別。其次，組件化其實是一種按照模板(HTML)+樣式(CSS)+邏輯(JS)三位一體的形式對面向對象的進一步抽象。因此咱們除了封裝組件自己，還要合理處理組件之間的關係，好比（邏輯）繼承、（樣式）擴展、（模板）嵌套和包含等，這些關係均可以歸爲依賴。其實組件化不是什麼新鮮的東西，之前的客戶端框架，像WinForm、WPF、Android等，它們從誕生的那天起就是組件化的。而前端領域發展曲折，是從展現頁面爲主的WebPage模式走過來的，近兩年才從客戶端框架經驗中引入了組件化思想。其實咱們不少前端工程化的問題均可以從客戶端那裏尋求解決方案。目前市面上的組件化框架不少，主要的有Vue、React、Angular 二、咱們公司 @鄭海波 的Regular、Avalon等。你感興趣能夠都研究一下，選擇一套中意的。其實Vue文檔中的對比其餘框架一文已經講得很詳細了。## 規範化模塊化和組件化肯定了開發模型，而這些東西的實現就須要規範去落實。規範化實際上是工程化中很重要的一個部分，項目初期規範制定的好壞會直接影響到後期的開發質量。我能想到的有如下一些內容：目錄結構的制定編碼規範先後端接口規範文檔規範組件管理Git分支管理Commit描述規範按期CodeReview視覺圖標規範...其中編碼規範最好採起ESLint和StyleLint等強制措施，配置git hooks能夠實現Lint不過不能提交代碼等機制，由於人是靠不住的。先後端接口管理能夠了解一下咱們公司出的NEI - 接口管理平臺。## 自動化做了這麼多年程序猿的我，一直秉持的一個理念是：任何簡單機械的重複勞動都應該讓機器去完成。
因此我也認爲，前端工程化的不少髒活累活都應該交給自動化工具來完成。### 圖標合併不要再用PS拼雪碧圖了，統一走Webpack吧；
不要再用Icomoon了，統一走Webpack吧。### 持續集成### 自動化構建### 自動化部署### 自動化測試前端自動化測試可以提升代碼質量、減小人肉測試等，這些優勢是不言而喻的。市面上前端測試框架有不少，選擇哪一個都不會有太大問題，咱們用的是：Karma + Mocha + Chai

非要介紹的話，那前端工程化就是這些：
1. 高性能
2. 穩定性（reliability）
3. 可用性（usability）
4. 可維護性（maintainability）
5. 可訪問性（accesibility）

每一個前端團隊都在打造本身的前端開發體系，這一般是一個東拼西湊，逐漸磨合的過程，在技術發展突飛猛進的今天，這樣的過程真的是不可抽象和複製的麼？本文但願可以經過系統的拆解前端開發體系爲你們提供體系設計思路參考。什麼是前端集成解決方案


前端集成解決方案，英文翻譯爲 Front-end Integrated Solution，縮寫fis，發音[fɪs]
前端集成解決方案並非一個新詞彙，將這個詞拆開來看，咱們能獲得：


前端：指前端領域，即web研發中經常使用的瀏覽器客戶端相關技術，好比html、js、css等
集成：將一些孤立的事物或元素經過某種方式改變原有的分散狀態集中在一塊兒，產生聯繫，從而構成一個有機總體的過程。[1]
解決方案：針對某些已經體現出的，或者能夠預期的問題，不足，缺陷，需求等等，所提出的一個解決問題的方案，同時可以確保加以有效的執行。[2]
總結來講，前端集成解決方案就是：


將前端研發領域中各類分散的技術元素集中在一塊兒，並對常見的前端開發問題、不足、缺陷和需求，所提出的一種解決問題的方案。
前端領域有哪些技術元素


前端行業經歷了這麼長時間的發展，技術元素很是豐富，這裏列舉出通常web團隊須要用到的技術元素：

開發規範：包括開發、部署的目錄規範，編碼規範等。不要小瞧規範的威力，能夠極大的提高開發效率，真正優秀的規範不會讓使用者感到約束，而是能幫助他們快速定位問題，提高效率。
模塊化開發：針對js、css，以功能或業務爲單元組織代碼。js方面解決獨立做用域、依賴管理、api暴露、按需加載與執行、安全合併等問題，css方面解決依賴管理、組件內部樣式管理等問題。是提高前端開發效率的重要基礎。如今流行的模塊化框架有requirejs、seajs等。
組件化開發：在模塊化基礎上，以頁面小部件(component)爲單位將頁面小部件的js、css、html代碼片斷放在一塊兒進行開發、維護，組件單元是資源獨立的，組件在系統內可複用。好比頭部(header)、尾部(footer)、搜索框(searchbar)、導航(menu)、對話框(dialog)等，甚至一些複雜的組件好比編輯器(editor)等。一般業務會針對組件化的js部分進行必要的封裝，解決一些常見的組件渲染、交互問題。
組件倉庫：有了組件化，咱們但願將一些很是通用的組件放到一個公共的地方供團隊共享，方便新項目複用，這個時候咱們就須要引入一個組件倉庫的東西，如今流行的組件庫有bower、component等。團隊發展到必定規模後，組件庫的需求會變得很是強烈。
性能優化：這裏的性能優化是指可以經過工程手段保證的性能優化點。因爲其內容比較豐富，就不在這裏展開了，感興趣的同窗能夠閱讀個人這兩篇文章 [1] [2]。性能優化是前端項目發展到必定階段必須經歷的過程。這部分我想強調的一點是 性能優化必定是一個工程問題和統計問題，不能用工程手段保證的性能優化是不靠譜的，優化時只考慮一個頁面的首次加載，不考慮全局在宏觀統計上的優化提高也是片面的。
項目部署：部署按照現行業界的分工標準，雖然不是前端的工做範疇，但它對性能優化有直接的影響，包括靜態資源緩存、cdn、非覆蓋式發佈等問題。合理的靜態資源資源部署能夠爲前端性能帶來較大的優化空間。
開發流程：完整的開發流程包括本地開發調試、視覺效果走查確認、先後端聯調、提測、上線等環節。對開發流程的改善能夠大幅下降開發的時間成本，工做這些年見過不少獨立的系統（cms系統、靜態資源推送系統）將開發流程割裂開，對前端開發的效率有嚴重的阻礙。
開發工具：這裏說的工具不是指IDE，而是工程工具，包括構建與優化工具、開發-調試-部署等流程工具，以及組件庫獲取、提交等相關工具，甚至運營、文檔、配置發佈等平臺工具。前端開發須要工具支持，這個問題的根本緣由來自前端領域語言特性（將來我會單獨寫一篇文章介紹前端領域語言缺陷問題）。前端開發所使用的語言（js、css、html）以及前端工程資源的加載與定位策略決定了前端工程必需要工具支持。因爲這些工具一般都是獨立的系統，要想把它們串聯起來，纔有了yeoman這樣的封裝。前面提到的7項技術元素都直接或間接的對前端開發工具設計產生必定的影響，所以可否串聯其餘技術要素，使得前端開發造成一個連貫可持續優化的開發體系，工具的設計相當重要。
以上8項，1-3是技術和業務相關的開發需求，4是技術沉澱與共享需求，5-8是工程優化需求。


通過這些年的工程領域實踐，我的以爲以上8項技術元素應該成爲絕大多數具備必定規模的前端開發團隊的標配。各位讀者能夠對照本身團隊現狀來思考一下團隊開發體系還有哪些環節須要完善。


攢一套前端集成解決方案


不難發現，其實其餘領域工程也基本須要解決上述這些問題。前端因爲其領域語言的獨特性，使得前端工程在解決這些問題上跟其餘工程有很大區別，所以至今也沒有造成一套比較好的理論體系指導團隊實踐前端工程。
仔細觀察過一些團隊的技術體系造成過程，你們都在努力拼湊上述8項技術元素的具體解決方案。單獨觀察每一項技術點，你或許會以爲都能各自找到已有的實現，但我要說，把全部8項技術點無縫的串聯起來，是一項很是有挑戰的工做，你信麼？相信真正經歷過這樣事情的同窗能明白我說的串聯成本問題。


假設咱們但願實踐一套完整的前端集成解決方案，好了，若是咱們單獨去看每一項技術點，均可能會找來一兩個現成的東西，假設咱們東拼西湊的找全了全部8項技術要素對應的具體實現。接下來要用了，它們能很完整流程的跑起來麼？


正如前面的貼圖展現的那樣，全部的技術點都有必定的內在聯繫：


模塊化開發涉及到性能優化、對構建工具又有必定的配套實現要求，也會影響開發規範的定製
組件化開發應該基於模塊化框架來加載其餘依賴的組件，若是組件化框架自帶模塊管理功能，那麼就可能致使工程性的性能優化實現困難
組件庫應該與組件化開發配套，組件倉庫中的組件都應該按照相同的標準來實現，不然下載的組件不具備可複用性、可移植性，就是去了倉庫的意義
咱們設計的開發規範工具是否能很容易的實現，若是部署上有特殊要求，工具是否能很容易的作出調整，而不是修改規範。
工具是否能提供接入公司已有流程中的接口，好比命令調用，若是工具須要一些系統環境支持，公司的ci流程中是否能支持等問題。
前端領域語言的特色決定了攢一套集成解決方案有很高的實現成本。由於前端語言缺乏包、導入、模塊等開發概念，這使得各個技術點的解決方案在設計的時候都是考慮被獨立使用的狀況下如何工做，所以或多或少的會延伸本身的職責。好比模塊化框架要附屬構建工具，甚至要求後端服務（好比combo），組件化框架自帶模塊化框架，構建工具自帶部署規範等，這就大大提升了將各個技術要素融合起來的成本。


總之，前述的8項技術要素之間有許多聯繫，這就爲打造一套完整連貫的前端集成解決方案帶來了較大的挑戰。如何兼顧規範、性能、框架、流程、部署等問題，就不是東拼西湊那麼簡單的事了。後面我會單獨撰文介紹如何實現一套集成解決方案。

一、關於組件化和模塊化，這個粒度實在是很差拿捏，模塊能夠很大，也能夠很小，小到一個函數成一個模塊，因此我以爲模塊應該主要是通用工具、api、類的封裝，而組件更多的是業務功能、UI塊的封裝


二、關於組件倉庫，其實bower、component之類的並不夠，還有文檔的生成與管理，使用別人寫的代碼，最快入手的就是看文檔，其次纔是看代碼


三、還有，測試。純工具和api之類的模塊，很容易自動化測試，蛋是到了組件層面，設計業務邏輯、UI什麼的，自動化太難了，還得靠人肉

fis-conf.js所在目錄即整個工程目錄，因此若是整個目錄下有不少文件，fis在構建的時候是會所有文件收集起來再做處理的，因此文件查找會成爲時間大頭。但通常狀況下前端工程也不會出現個別多的文件，若是你的工程裏混有一些非前端代碼，好比nodejs的node_modules等，建議用 fis.config.set('project.exclude', /正則/); 來排除掉。


固然，有些前端工程確實特別大，咱們在百度的時候採用的作法是把一個網站的代碼拆成多個子系統，每一個子系統一個fis-conf.js，每一個子系統一個svn倉庫，子系統能夠獨立編譯、獨立上線發佈。這樣系統的並行開發程度就提升了不少。子系統中有一個特殊的子系統，叫公共資源子系統(common)，其餘子系統不容許有相互的資源依賴，只容許它們惟一依賴公共資源子系統。而依賴的功能是經過模塊化框架實現的。


所有放在一塊兒也沒有什麼問題，就是構建速度差一些，代碼合併會多一些，規模上會有必定的瓶頸。分開來也會有一些小問題，並且框架設計成本略高，有時候甚至要在後端模板層實現一套後端的模塊化框架，略麻煩。


你用的spmx是我以前一個下午隨便搞的，不是很嚴謹，也沒有充分考慮到seajs的設計理念，因此可能用起來效果稍差一些，若是有須要能夠在spmx的issues裏提，我儘可能知足，或者給大家開權限，以及npm上的發佈權限，若是能夠將它發展成一個強大的解決方案，那真是一件很是很少的事情。

關於前端工程的核心問題


說的有點大，其實呢，前端工程只有兩個核心問題：


一個是 資源定位，另外一個是 模塊化開發。
fis從你的描述中我已經感受大家用的比較好了，這裏我能夠作一個總結和補充：

前端工程的全部工做都是圍繞着這兩個核心問題展開的。資源定位的主要思想就是將 工程路徑 轉換爲 部署路徑，也就是把相對路徑變成絕對路徑而且加上md5戳和域名。這樣作的目的是解決靜態資源緩存更新的問題，同時爲模塊化開發這個問題作準備。由於只有將全部相對路徑轉換成絕對路徑才能實現模塊的獨立性，模塊才能被任何地方使用都不用擔憂裏面資源加載的問題。你所喜歡的內嵌功能，也是要創建在路徑轉換的基礎上，由於內嵌會改變路徑關係，絕對化處理可讓任意文件間的內嵌成爲可能。


模塊化開發呢，在解決了資源定位的前提下，核心問題就是依賴管理和加載了。fis最推崇的作法就是：


儘可能依靠框架實現，最少依賴構建工具處理。
就是說，儘可能不要讓構建工具作太多事情，由於那很黑盒，fis的設計是，構建工具只負責生成依賴關係表，這就足夠了，而後框架本身決定何時該加載哪些資源，表的關係可讓框架加載時完成按需、請求合併等需求。


基於上述設計理念，能發揮fis最大價值的地方就在於如何利用靜態資源依賴表來實現一個合理的模塊化框架。
spmx是我根據seajs的模塊化設計而作的適配，其實能夠更精簡一些的。我到UC以後根據他們的業務特色與小夥伴 @hinc 又設計開發了一個模塊化框架，並以此衍生出了一套解決方案，能夠做爲大家的參考。今年還作了一個分享，能夠看看：

前端工程能夠在 前端開發，性能優化，持續集成，自動部署、模塊生態、甚至 CMS運營系統 中都能發揮功效，其中CMS運營系統的前端工程化實踐咱們還在探索中，你能夠看一下本身團隊還有哪些須要補充。


模塊化框架和工具作好了以後，就在模塊化框架裏作性能優化，好比請求合併、按需加載、localstorage緩存（移動端）等，而後就是開發過程和持續集成與部署結合，內網搭建jenkins，提交即構建，構建結果存放到代碼倉庫 ，而後實現部署推送。接下來將歷往項目中的通用模塊抽取出來，放到生態裏，好比GitHub上，而後在開發工具中集成一個install的小工具，用於項目初期獲取這些模塊，能夠進一步提升效率。最多見的例子就是處理css合併了，css中常常會有圖片資源的路徑引用，若是保留相對路徑，會對css文件合併帶來不少負擔。有這麼幾種狀況：


代碼中使用相對路徑，合併後不作任何路徑處理。這種狀況下，有兩種開發模式：
全部css在同級維護，構建中合併css，而且合併後的css也是同級目錄。優勢是不依賴工具，簡單直觀。缺點是不能把css和對應的html、js維護在一塊兒，並且項目變大以後一個目錄下都是css文件，又不能分二級，很噁心。
全部css中寫圖片路徑的時候，都是寫那個合併後文件的相對路徑。優勢是css能夠分級，可是寫資源地址要時刻想着是在另一個文件中使用的，這和寫絕對路徑有什麼分別？並且IDE不友好，不少IDE會報錯，別小看這個，不少程序員都是神經質，煩。
代碼中使用相對路徑，合併後根據合併後生成的文件的位置作相對路徑計算。解決了1.2中的問題，經過工具從新計算相對路徑。缺點是同一個文件只能被合併，不能被其餘方式複用，不然會帶來相對路徑不一致問題。並且這都用上工具了，爲啥不直接轉成絕對路徑。
代碼中使用相對路徑，合併後替換成絕對路徑。先說缺點，依賴工具，沒了。而後說說優勢：
開發中使用相對路徑，各類直觀與友好
沒有規範，組件任意移植，部署路徑都能正確
目錄任意分級，能夠實現徹底的組件化/模塊化開發
有些時候，咱們可能須要把css的文件嵌入到js中，經過js動態插入到頁面上，或者嵌入到html的style標籤中使用，轉換成絕對路徑永遠不用擔憂資源找不到的狀況
combo隨便，仍是由於資源定位都是絕對路徑。
js也有相同問題，當你在js中想要經過邏輯加載一個圖片、加載一個css文件，加載其餘js文件的時候，使用絕對路徑可讓這個js不管在哪一個頁面，不管在哪一級路徑下都能正確運行，有百利而無一害。（其實路徑會很長，算是一害）。


有了絕對路徑，資源的合併、複用、移動才能不被運行時的文檔路徑限制。我以爲，絕對路徑才叫資源定位，纔是真實的完整的定位信息，相對路徑更像是一種「變量」，它使得同一段代碼在不一樣的路徑下執行會有可能發生定位錯誤。


其實前端頁面也是一種GUI軟件，傳統的桌面軟件，全部程序資源都部署（安裝）在客戶端，因此歷來沒有在資源上遇到過想前端的這種的定位概念。前端程序資源是部署在其餘設備上的，經過運行時加載到客戶端來執行，這種程序資源部署上的差別我以爲正是前端工程與GUI軟件工程的最大區別，幾乎全部前端開發、維護、模塊化、性能優化等特殊的工程問題都是圍繞着這個差別點產生的。

原文：http://www.javashuo.com/article/p-xruxbcuq-s.html