前端工程——基礎(chǔ)篇

原文出處：https://github.com/fouber/blog/issues/10
作者：fouber

---

目錄

喂喂喂，那個切圖的，把頁面寫好就發(fā)給研發(fā)工程師套模板吧。

你好，切圖仔。

不知道你的團(tuán)隊(duì)如何定義前端開發(fā)，據(jù)我所知，時(shí)至今日仍然有很多團(tuán)隊(duì)會把前端開發(fā)歸類為產(chǎn)品或者設(shè)計(jì)崗位，雖然身份之爭多少有些無謂，但我對這種偏見還是心存芥蒂，醞釀了許久，決定寫一個系列的文章，試著從工程的角度系統(tǒng)的介紹一下我對前端，尤其是Web前端的理解。

只要我們還把自己的工作看作為一項(xiàng)軟件開發(fā)活動，那么我相信讀過下面的內(nèi)容你也一定會有所共鳴。

前端，是一種GUI軟件

現(xiàn)如今前端可謂包羅萬象，產(chǎn)品形態(tài)五花八門，涉獵極廣，什么高大上的基礎(chǔ)庫/框架，拽炫酷的宣傳頁面，還有屌炸天的小游戲……不過這些一兩個文件的小項(xiàng)目并非是前端技術(shù)的主要應(yīng)用場景，更具商業(yè)價(jià)值的則是復(fù)雜的Web應(yīng)用，它們功能完善，界面繁多，為用戶提供了完整的產(chǎn)品體驗(yàn)，可能是新聞聚合網(wǎng)站，可能是在線購物平臺，可能是社交網(wǎng)絡(luò)，可能是金融信貸應(yīng)用，可能是音樂互動社區(qū)，也可能是視頻上傳與分享平臺……

從本質(zhì)上講，所有Web應(yīng)用都是一種運(yùn)行在網(wǎng)頁瀏覽器中的軟件，這些軟件的圖形用戶界面（Graphical User Interface，簡稱GUI）即為前端。

如此復(fù)雜的Web應(yīng)用，動輒幾十上百人共同開發(fā)維護(hù)，其前端界面通常也頗具規(guī)模，工程量不亞于一般的傳統(tǒng)GUI軟件：

盡管Web應(yīng)用的復(fù)雜程度與日俱增，用戶對其前端界面也提出了更高的要求，但時(shí)至今日仍然沒有多少前端開發(fā)者會從軟件工程的角度去思考前端開發(fā)，來助力團(tuán)隊(duì)的開發(fā)效率，更有甚者還對前端保留著”如玩具般簡單“的刻板印象，日復(fù)一日，刀耕火種。

歷史悠久的前端開發(fā)，始終像是放養(yǎng)的野孩子，原始如斯，不免讓人慨嘆！

前端工程的三個階段

現(xiàn)在的前端開發(fā)倒也并非一無所有，回顧一下曾經(jīng)經(jīng)歷過或聽聞過的項(xiàng)目，為了提升其前端開發(fā)效率和運(yùn)行性能，前端團(tuán)隊(duì)的工程建設(shè)大致會經(jīng)歷三個階段：

第一階段：庫/框架選型

前端工程建設(shè)的第一項(xiàng)任務(wù)就是根據(jù)項(xiàng)目特征進(jìn)行技術(shù)選型。

基本上現(xiàn)在沒有人完全從0開始做網(wǎng)站，哪怕是政府項(xiàng)目用個jquery都很正常吧，React/Angularjs等框架橫空出世，解放了不少生產(chǎn)力，合理的技術(shù)選型可以為項(xiàng)目節(jié)省許多工程量這點(diǎn)毋庸置疑。

第二階段：簡單構(gòu)建優(yōu)化

選型之后基本上就可以開始敲碼了，不過光解決開發(fā)效率還不夠，必須要兼顧運(yùn)行性能。前端工程進(jìn)行到第二階段會選型一種構(gòu)建工具，對代碼進(jìn)行壓縮，校驗(yàn)，之后再以頁面為單位進(jìn)行簡單的資源合并。

前端開發(fā)工程化程度之低，常常出乎我的意料，我之前在百度工作時(shí)是沒有多少概念的，直到離開大公司的溫室，去到業(yè)界與更多的團(tuán)隊(duì)交流才發(fā)現(xiàn)，能做到這個階段在業(yè)界來說已然超出平均水平，屬于“具備較高工程化程度”的團(tuán)隊(duì)了，查看網(wǎng)上形形色色的網(wǎng)頁源代碼，能做到最基本的JS/CSS壓縮的Web應(yīng)用都已跨入標(biāo)準(zhǔn)互聯(lián)網(wǎng)公司行列，不難理解為什么很多前端團(tuán)隊(duì)對于前端工程構(gòu)建的認(rèn)知還僅停留在“壓縮、校驗(yàn)、合并”這種程度。

第三階段：JS/CSS模塊化開發(fā)

分而治之是軟件工程中的重要思想，是復(fù)雜系統(tǒng)開發(fā)和維護(hù)的基石，這點(diǎn)放在前端開發(fā)中同樣適用。在解決了基本開發(fā)效率運(yùn)行效率問題之后，前端團(tuán)隊(duì)開始思考維護(hù)效率，模塊化是目前前端最流行的分治手段。

很多人覺得模塊化開發(fā)的工程意義是復(fù)用，我不太認(rèn)可這種看法，在我看來，模塊化開發(fā)的最大價(jià)值應(yīng)該是分治，是分治，分治?。ㄖ卣f三）。

不管你將來是否要復(fù)用某段代碼，你都有充分的理由將其分治為一個模塊。

JS模塊化方案很多，AMD/CommonJS/UMD/ES6 Module等，對應(yīng)的框架和工具也一大堆，說起來很煩，大家自行百度吧；CSS模塊化開發(fā)基本都是在less、sass、stylus等預(yù)處理器的import/mixin特性支持下實(shí)現(xiàn)的。

雖然這些技術(shù)由來已久，在如今這個“言必及React”的時(shí)代略顯落伍，但想想業(yè)界的絕大多數(shù)團(tuán)隊(duì)的工程化落后程度，放眼望去，毫不夸張的說，能達(dá)到第三階段的前端團(tuán)隊(duì)已屬于高端行列，基本具備了開發(fā)維護(hù)一般規(guī)模Web應(yīng)用的能力。

然而，做到這些就夠了么？Naive！

第四階段

前端是一種技術(shù)問題較少、工程問題較多的軟件開發(fā)領(lǐng)域。

當(dāng)我們要開發(fā)一款完整的Web應(yīng)用時(shí)，前端將面臨更多的工程問題，比如：

• 大體量：多功能、多頁面、多狀態(tài)、多系統(tǒng)；
• 大規(guī)模：多人甚至多團(tuán)隊(duì)合作開發(fā)；
• 高性能：CDN部署、緩存控制、文件指紋、緩存復(fù)用、請求合并、按需加載、同步/異步加載、移動端首屏CSS內(nèi)嵌、HTTP 2.0服務(wù)端資源推送。

擴(kuò)展閱讀：大公司里怎樣開發(fā)和部署前端代碼？

這些無疑是一系列嚴(yán)肅的系統(tǒng)工程問題。

前面講的三個階段雖然相比曾經(jīng)“茹毛飲血”的時(shí)代進(jìn)步不少，但用于支撐第四階段的多人合作開發(fā)以及精細(xì)的性能優(yōu)化似乎還欠缺點(diǎn)什么。

到底，缺什么呢？

沒有銀彈

讀過《人月神話》的人應(yīng)該都聽說過，軟件工程?沒有銀彈。沒錯，前端開發(fā)同樣沒有銀彈，可是現(xiàn)在是連?鉛彈都沒有的年月！（剛有了BB彈，摔）

前端歷來以“簡單”著稱，在前端開發(fā)者群體中，小而美的價(jià)值觀占據(jù)著主要的話語權(quán)，甚至成為了某種信仰，想與其他人交流一下工程方面的心得，得到的回應(yīng)往往都是兩個字：太重。

重你妹！你的腦容量只有4K嗎？

工程方案其實(shí)也可以小而美！只不過它的小而美不是指代碼量，而是指“規(guī)則”。找到問題的根源，用最少最簡單明了的規(guī)則制定出最容易遵守最容易理解的開發(fā)規(guī)范或工具，以提升開發(fā)效率和工程質(zhì)量，這同樣是小而美的典范！

2011年我有幸參與到?FIS?項(xiàng)目中，與百度眾多大中型項(xiàng)目的前端研發(fā)團(tuán)隊(duì)共同合作，不斷探索實(shí)踐前端開發(fā)的工程化解決方案，13年離開百度去往UC，面對完全不同的產(chǎn)品形態(tài)，不同的業(yè)務(wù)場景，不同的適配終端，甚至不同的網(wǎng)絡(luò)環(huán)境，過往的方法論仍然能夠快速落地，為多個團(tuán)隊(duì)的不同業(yè)務(wù)場景量身定制出合理的前端解決方案。

這些經(jīng)歷讓我明悟了一個道理：

進(jìn)入第四階段，我們只需做好兩件事就能大幅提升前端開發(fā)效率，并且兼顧運(yùn)行性能，那就是——組件化開發(fā)與資源管理。

第一件事：組件化開發(fā)

分治的確是非常重要的工程優(yōu)化手段。在我看來，前端作為一種GUI軟件，光有JS/CSS的模塊化還不夠，對于UI組件的分治也有著同樣迫切的需求：

如上圖，這是我所信仰的前端組件化開發(fā)理念，簡單解讀一下：

1. 頁面上的每個?獨(dú)立的?可視/可交互區(qū)域視為一個組件；
2. 每個組件對應(yīng)一個工程目錄，組件所需的各種資源都在這個目錄下就近維護(hù)；
3. 由于組件具有獨(dú)立性，因此組件與組件之間可以?自由組合；
4. 頁面只不過是組件的容器，負(fù)責(zé)組合組件形成功能完整的界面；
5. 當(dāng)不需要某個組件，或者想要替換組件時(shí)，可以整個目錄刪除/替換。

其中第二項(xiàng)描述的就近維護(hù)原則，是我覺得最具工程價(jià)值的地方，它為前端開發(fā)提供了很好的分治策略，每個開發(fā)者都將清楚的知道，自己所開發(fā)維護(hù)的功能單元，其代碼必然存在于對應(yīng)的組件目錄中，在那個目錄下能找到有關(guān)這個功能單元的所有內(nèi)部邏輯，樣式也好，JS也好，頁面結(jié)構(gòu)也好，都在那里。

組件化開發(fā)具有較高的通用性，無論是前端渲染的單頁面應(yīng)用，還是后端模板渲染的多頁面應(yīng)用，組件化開發(fā)的概念都能適用。組件HTML部分根據(jù)業(yè)務(wù)選型的不同，可以是靜態(tài)的HTML文件，可以是前端模板，也可以是后端模板：

不同的技術(shù)選型決定了不同的組件封裝和調(diào)用策略。

基于這樣的工程理念，我們很容易將系統(tǒng)以獨(dú)立的組件為單元進(jìn)行分工劃分：

由于系統(tǒng)功能被分治到獨(dú)立的模塊或組件中，粒度比較精細(xì)，組織形式松散，開發(fā)者之間不會產(chǎn)生開發(fā)時(shí)序的依賴，大幅提升并行的開發(fā)效率，理論上允許隨時(shí)加入新成員認(rèn)領(lǐng)組件開發(fā)或維護(hù)工作，也更容易支持多個團(tuán)隊(duì)共同維護(hù)一個大型站點(diǎn)的開發(fā)。

結(jié)合前面提到的模塊化開發(fā)，整個前端項(xiàng)目可以劃分為這么幾種開發(fā)概念：

以上5種開發(fā)概念以相對較少的規(guī)則組成了前端開發(fā)的基本工程結(jié)構(gòu)，基于這些理念，我眼中的前端開發(fā)就成了這個樣子：

示意圖	描述
	整個Web應(yīng)用由頁面組成
	頁面由組件組成
	一個組件一個目錄，資源就近維護(hù)
	組件可組合，

組件的JS可依賴其他JS模塊，
CSS可依賴其他CSS單元 |

綜合上面的描述，對于一般中小規(guī)模的項(xiàng)目，大致可以規(guī)劃出這樣的源碼目錄結(jié)構(gòu)：

如果項(xiàng)目規(guī)模較大，涉及多個團(tuán)隊(duì)協(xié)作，還可以將具有相關(guān)業(yè)務(wù)功能的頁面組織在一起，形成一個子系統(tǒng)，進(jìn)一步將整個站點(diǎn)拆分出多個子系統(tǒng)來分配給不同團(tuán)隊(duì)維護(hù)，針對這種情況后面我會單開文章詳細(xì)介紹。

以上架構(gòu)設(shè)計(jì)歷經(jīng)許多不同公司不同業(yè)務(wù)場景的前端團(tuán)隊(duì)驗(yàn)證，收獲了不錯的口碑，是行之有效的前端工程分治方案。

吐槽：我本人非常反對某些前端團(tuán)隊(duì)將前端開發(fā)劃分為“JS開發(fā)”和“頁面重構(gòu)”兩種崗位，更傾向于組件粒度的開發(fā)理念，對GUI軟件開發(fā)的分工規(guī)劃應(yīng)該以功能為單位，而不是開發(fā)語言；對開發(fā)者的技術(shù)要求也應(yīng)該是掌握完整的端內(nèi)技術(shù)。

第二件事：“智能”靜態(tài)資源管理

上面提到的模塊化/組件化開發(fā)，僅僅描述了一種開發(fā)理念，也可以認(rèn)為是一種開發(fā)規(guī)范，倘若你認(rèn)可這規(guī)范，對它的分治策略產(chǎn)生了共鳴，那我們就可以繼續(xù)聊聊它的具體實(shí)現(xiàn)了。

很明顯，模塊化/組件化開發(fā)之后，我們最終要解決的，就是模塊/組件加載的技術(shù)問題。然而前端與客戶端GUI軟件有一個很大的不同：

前端是一種遠(yuǎn)程部署，運(yùn)行時(shí)增量下載的GUI軟件

前端應(yīng)用沒有安裝過程，其所需程序資源都部署在遠(yuǎn)程服務(wù)器，用戶使用瀏覽器訪問不同的頁面來加載不同的資源，隨著頁面訪問的增加，漸進(jìn)式的將整個程序下載到本地運(yùn)行，“增量下載”是前端在工程上有別于客戶端GUI軟件的根本原因。

上圖展示了一款界面繁多功能豐富的應(yīng)用，如果采用Web實(shí)現(xiàn)，相信也是不小的體量，如果用戶第一次訪問頁面就強(qiáng)制其加載全站靜態(tài)資源再展示，相信會有很多用戶因?yàn)槭ツ托亩魇А８鶕?jù)“增量”的原則，我們應(yīng)該精心規(guī)劃每個頁面的資源加載策略，使得用戶無論訪問哪個頁面都能按需加載頁面所需資源，沒訪問過的無需加載，訪問過的可以緩存復(fù)用，最終帶來流暢的應(yīng)用體驗(yàn)。

這正是Web應(yīng)用“免安裝”的魅力所在。

由“增量”原則引申出的前端優(yōu)化技巧幾乎成為了性能優(yōu)化的核心，有加載相關(guān)的按需加載、延遲加載、預(yù)加載、請求合并等策略；有緩存相關(guān)的瀏覽器緩存利用，緩存更新、緩存共享、非覆蓋式發(fā)布等方案；還有復(fù)雜的BigRender、BigPipe、Quickling、PageCache等技術(shù)。這些優(yōu)化方案無不圍繞著如何將增量原則做到極致而展開。

所以我覺得：

第四階段前端開發(fā)最迫切需要做好的就是在基礎(chǔ)架構(gòu)中貫徹增量原則。

相信這種貫徹不會隨著時(shí)間的推移而改變，在可預(yù)見的未來，無論在HTTP1.x還是HTTP2.0時(shí)代，無論在ES5亦或者ES6/7時(shí)代，無論是AMD/CommonJS/UMD亦或者ES6 module時(shí)代，無論端內(nèi)技術(shù)如何變遷，我們都有足夠充分的理由要做好前端程序資源的增量加載。

正如前面說到的，第三階段前端工程缺少點(diǎn)什么呢？我覺得是在其基礎(chǔ)架構(gòu)中缺少這樣一種“智能”的資源加載方案。沒有這樣的方案，很難將前端應(yīng)用的規(guī)模發(fā)展到第四階段，很難實(shí)現(xiàn)落地前面介紹的那種組件化開發(fā)方案，也很難讓多方合作高效率的完成一項(xiàng)大型應(yīng)用的開發(fā)，并保證其最終運(yùn)行性能良好。在第四階段，我們需要強(qiáng)大的工程化手段來管理”玩具般簡單“的前端開發(fā)。

在我的印象中，F(xiàn)acebook是這方面探索的偉大先驅(qū)之一，早在2010年的Velocity China大會上，來自Facebook的David Wei博士就為業(yè)界展示了他們令人驚艷的靜態(tài)網(wǎng)頁資源管理和優(yōu)化技術(shù)。

David Wei博士在當(dāng)年的交流會上提到過一些關(guān)于Facebook的一些產(chǎn)品數(shù)據(jù)：

• Facebook整站有10000+個靜態(tài)資源；
• 每個靜態(tài)資源都有可能被翻譯成超過100種語言版本；
• 每種資源又會針對瀏覽器生成3種不同的版本；
• 要針對不同帶寬的用戶做5種不同的打包方法；
• 有3、4個不同的用戶組，用于小批次體驗(yàn)新的產(chǎn)品功能；
• 還要考慮不同的送達(dá)方法，可以直接送達(dá)，或者通過iframe的方式提升資源并行加載的速度；
• 靜態(tài)資源的壓縮和非壓縮狀態(tài)可切換，用于調(diào)試和定位線上問題

這是一個狀態(tài)爆炸的問題，將所有狀態(tài)乘起來，整個網(wǎng)站的資源組合方式會達(dá)到幾百萬種之多（去重之后統(tǒng)計(jì)大概有300萬種組合方式）。支撐這么大規(guī)模前端項(xiàng)目運(yùn)行的底層架構(gòu)正是魏博士在那次演講中分享的Static Resource Management System(靜態(tài)資源管理系統(tǒng))，用以解決Facebook項(xiàng)目中有關(guān)前端工程的3D問題（Development，Deployment，Debugging）。

那段時(shí)間?FIS?項(xiàng)目正好遇到瓶頸，當(dāng)時(shí)的FIS還是一個用php寫的task-based構(gòu)建工具，那時(shí)候?qū)τ谇岸斯こ痰恼J(rèn)知度很低，覺得前端構(gòu)建不就是幾個壓縮優(yōu)化校驗(yàn)打包任務(wù)的組合嗎，寫好流程調(diào)度，就針對不同需求寫插件唄，看似非常簡單。但當(dāng)我們支撐越來越多的業(yè)務(wù)團(tuán)隊(duì)，接觸到各種不同的業(yè)務(wù)場景時(shí)，我們深刻的感受到task-based工具的粗糙，團(tuán)隊(duì)每天疲于根據(jù)各種業(yè)務(wù)場景編寫各種打包插件，構(gòu)建邏輯異常復(fù)雜，隱隱看到不可控的跡象。

我們很快意識到把基礎(chǔ)架構(gòu)放到構(gòu)建工具中實(shí)現(xiàn)是一件很愚蠢的事，試圖依靠構(gòu)建工具實(shí)現(xiàn)各種優(yōu)化策略使得構(gòu)建變成了一個巨大的黑盒，一旦發(fā)生問題，定位起來非常困難，而且每種業(yè)務(wù)場景都有不同的優(yōu)化需求，構(gòu)建工具只能通過靜態(tài)分析來優(yōu)化加載，具有很大的局限性，單頁面/多頁面/PC端/移動端/前端渲染/后端渲染/多語言/多皮膚/高級優(yōu)化等等資源加載問題，總不能給每個都寫一套工具吧，更何況這些問題彼此之間還可以有多種組合應(yīng)用，工具根本寫不過來。

Facebook的做法無疑為我們亮起了一盞明燈，不過可惜它并不開源（不是技術(shù)封鎖，而是這個系統(tǒng)依賴FB體系中的其他方面，通用性不強(qiáng)，開源意義不大），我們只能嘗試挖掘相關(guān)信息，網(wǎng)上對它的完整介紹還是非常非常少，分析facebook的前端代碼也沒有太多收獲，后來無意中發(fā)現(xiàn)了facebook使用的項(xiàng)目管理工具phabricator中的一個靜態(tài)管理方案Celerity，以及相關(guān)的說明，看它的描述很像是Facebook靜態(tài)資源管理系統(tǒng)的一個mini版！

簡單看過整個系統(tǒng)之后發(fā)現(xiàn)原理并不復(fù)雜（小而美的典范），它是通過一個小工具掃描所有靜態(tài)資源，生成一張資源表，然后有一個PHP實(shí)現(xiàn)的資源管理框架（Celerity）提供了資源加載接口，替代了傳統(tǒng)的script/link等靜態(tài)的資源加載標(biāo)簽，最終通過查表來加載資源。

雖然沒有真正看過FB的那套系統(tǒng)，但眼前的這個小小的框架給了當(dāng)時(shí)的我們足夠多的啟示：

靜態(tài)資源管理系統(tǒng) = 資源表 + 資源加載框架

多么優(yōu)雅的實(shí)現(xiàn)?。?/p>

資源表是一份數(shù)據(jù)文件（比如JSON），是項(xiàng)目中所有靜態(tài)資源（主要是JS和CSS）的構(gòu)建信息記錄，通過構(gòu)建工具掃描項(xiàng)目源碼生成，是一種k-v結(jié)構(gòu)的數(shù)據(jù)，以每個資源的id為key，記錄了資源的類別、部署路徑、依賴關(guān)系、打包合并等內(nèi)容，比如：

{
    "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"
    }
}

而資源加載框架則提供一些資源引用的API，讓開發(fā)者根據(jù)id來引用資源，替代靜態(tài)的script/link標(biāo)簽來收集、去重、按需加載資源。調(diào)用這些接口時(shí)，框架通過查表來查找資源的各項(xiàng)信息，并遞歸查找其依賴的資源的信息，然后我們可以在這個過程中實(shí)現(xiàn)各種性能優(yōu)化算法來“智能”加載資源。

根據(jù)業(yè)務(wù)場景的不同，加載框架可以在瀏覽器中用JS實(shí)現(xiàn)，也可以是后端模板引擎中用服務(wù)端語言實(shí)現(xiàn)，甚至二者的組合，不一而足。

有關(guān)加載框架的具體實(shí)現(xiàn)我曾寫過很多文章介紹，可以擴(kuò)展閱讀：

• 前端工程與性能優(yōu)化
• 前端工程與模塊化框架

這種設(shè)計(jì)很快被驗(yàn)證具有足夠的靈活性，能夠完美支撐不同團(tuán)隊(duì)不同技術(shù)規(guī)范下的性能優(yōu)化需求，前面提到的按需加載、延遲加載、預(yù)加載、請求合并、文件指紋、CDN部署、Bigpipe、Quickling、BigRender、首屏CSS內(nèi)嵌、HTTP 2.0服務(wù)端推送等等性能優(yōu)化手段都可以很容易的在這種架構(gòu)上實(shí)現(xiàn)，甚至可以根據(jù)性能日志自動進(jìn)行優(yōu)化（Facebook已實(shí)現(xiàn)）。

因?yàn)橛辛速Y源表，我們可以很方便的控制資源加載，通過各種手段在運(yùn)行時(shí)計(jì)算頁面的資源使用情況，從而獲得最佳加載性能。無論是前端渲染的單頁面應(yīng)用，還是后端渲染的多頁面應(yīng)用，這種方法都同樣適用。

此外，它還很巧妙的約束了構(gòu)建工具的職責(zé)——只生成資源表。資源表是非常通用的數(shù)據(jù)結(jié)構(gòu)，無論什么業(yè)務(wù)場景，其業(yè)務(wù)代碼最終都可以被掃描為相同結(jié)構(gòu)的表數(shù)據(jù)，并標(biāo)記資源間的依賴關(guān)系，有了表之后我們只需根據(jù)不同的業(yè)務(wù)場景定制不同的資源加載框架就行了，從此徹底告別一個團(tuán)隊(duì)維護(hù)一套工具的時(shí)代?。?！

恩，如你所見，雖然徹底告別了一個團(tuán)隊(duì)一套工具的時(shí)代，但似乎又進(jìn)入了一個團(tuán)隊(duì)一套框架的時(shí)代。其實(shí)還是有差別的，因?yàn)榭蚣芫哂泻艽蟮撵`活性，而且不那么黑盒，采用框架實(shí)現(xiàn)資源管理相比構(gòu)建更容易調(diào)試、定位和升級變更。

深耕靜態(tài)資源加載框架可以帶來許多收益，而且有足夠的靈活性和健壯性面向未來的技術(shù)變革，這個我們留作后話。

總結(jié)

回顧一下前面提到過的前端工程三個階段：

• 第一階段：庫/框架選型
• 第二階段：簡單構(gòu)建優(yōu)化
• 第三階段：JS/CSS模塊化開發(fā)

現(xiàn)在補(bǔ)充上第四階段：

• 第四階段：組件化開發(fā)與資源管理

由于先天缺陷，前端相比其他軟件開發(fā)，在基礎(chǔ)架構(gòu)上更加迫切的需要組件化開發(fā)和資源管理，而解決資源管理的方法其實(shí)一點(diǎn)也不復(fù)雜：

一個通用的資源表生成工具 + 基于表的資源加載框架

近幾年來各種你聽到過的各種資源加載優(yōu)化策略大部分都可以在這樣一套基礎(chǔ)上實(shí)現(xiàn)，而這種優(yōu)化對于業(yè)務(wù)來說是完全透明的，不需要重構(gòu)的性能優(yōu)化——這不正是我們一直所期盼的嗎？正如魏小亮博士所說：我們可以把優(yōu)秀的人集中起來去優(yōu)化加載。

如何選型技術(shù)、如何定制規(guī)范、如何分治系統(tǒng)、如何優(yōu)化性能、如何加載資源，當(dāng)你從切圖開始轉(zhuǎn)變?yōu)樗伎歼@些問題的時(shí)候，我想說：

你好，工程師！

前端工程其實(shí)是一個很大的話題，開發(fā)僅是其中的一部分。