作為開(kāi)發(fā)，不僅僅是前端，優(yōu)化總是你繞不開(kāi)的事，我們的目標(biāo)就是要產(chǎn)品變得更快。優(yōu)化的對(duì)象不僅僅指產(chǎn)品本身，還有我們?nèi)粘５拈_(kāi)發(fā)流程。從加入團(tuán)隊(duì) 到現(xiàn)在，大概有一半左右的時(shí)間花在了優(yōu)化上，期間遇到了很多問(wèn)題，回過(guò)頭看，優(yōu)化這件事情并不是那么簡(jiǎn)單，也是些很瑣碎的事情，要打造一個(gè)無(wú)痛的開(kāi)發(fā)流 程，并且能夠相對(duì)輕松的對(duì)產(chǎn)品持續(xù)優(yōu)化真的不輕松。沒(méi)有銀彈，任何項(xiàng)目都要花很多時(shí)間和精力。但任何值得改善的地方能夠有所提升都讓我們覺(jué)得努力沒(méi)白費(fèi)。 有時(shí)候只想懶一點(diǎn)，從枯燥的重復(fù)中解放出來(lái)。

剛進(jìn)來(lái)時(shí)，加上我團(tuán)隊(duì)中一共3個(gè)人專職前端開(kāi)發(fā)。項(xiàng)目比較簡(jiǎn)單，前人已經(jīng)做好了模塊化，只是覺(jué) 得還不夠徹底。后來(lái)項(xiàng)目慢慢變得龐大，加上重構(gòu)同學(xué)，人員最多的時(shí)候達(dá)到了13人。這個(gè)過(guò)程中遇到了很多問(wèn)題，前端框架演變了三次，都是因?yàn)橛龅搅艘恍┘?手的問(wèn)題，而不得已做出調(diào)整，沒(méi)有絕對(duì)的好壞，只有合不合適。

11.0時(shí)代

前期模塊化已經(jīng)做的不錯(cuò)了，至少不必花大量時(shí)間去重構(gòu)代碼。模塊劃分如下圖，邏輯層次上還是比較清晰。

前端模塊化依賴的主流庫(kù)也就數(shù)國(guó)內(nèi)的Seajs和國(guó)外的requirejs，這里就不陳述。采用了Seajs作為模塊管理器，zepto作為基礎(chǔ)庫(kù)文件，lib主要包含了項(xiàng)目中用到的主流第三方庫(kù)文件。

我們知道模塊化帶來(lái)的最大弊端便是HTTP請(qǐng)求數(shù)增加，所以上線的時(shí)候必須合并文件。下圖中的package模塊是文件大集合，打包了很多個(gè)JS模塊，除去上圖中的基礎(chǔ)庫(kù)文件和業(yè)務(wù)模塊層，在上線的時(shí)候大部分文件都被打包在package.js里。

大部分頁(yè)面的JS請(qǐng)求是這樣的：

細(xì)心點(diǎn)的同學(xué)可能注意到兩個(gè)問(wèn)題：文件的大小和加載時(shí)間。剛才的截圖還是在PC端截取的，手機(jī)和不同網(wǎng)絡(luò)環(huán)境的表現(xiàn)會(huì)更加糟糕。

現(xiàn)在來(lái)看下目錄

存在的問(wèn)題：

• 目錄看起來(lái)算規(guī)范，但實(shí)際上是公共的和業(yè)務(wù)的混在一塊。
• 大部分文件合并在一個(gè)文件，合并策略不合理。
• 由第二點(diǎn)引發(fā)的第三個(gè)問(wèn)題，發(fā)布上線時(shí)，只要兩人發(fā)布涉及到package文件，沖突必然發(fā)生。
• 發(fā)布時(shí)需要down下上一次的文件，對(duì)照合并的新文件，以免發(fā)錯(cuò)。
• 注意，第四點(diǎn)是人工。一不小心發(fā)錯(cuò)，或者把他人剛發(fā)布的文件覆蓋了，這種事情發(fā)生10+次。
• 只有一臺(tái)測(cè)試機(jī)器，測(cè)試環(huán)境經(jīng)常覆蓋是常事。
• 版本控制問(wèn)題，不以SVN為版本，而是預(yù)發(fā)布機(jī)器上代碼，管理混亂

不敢想象如果10+人的團(tuán)隊(duì)一起在這種模式下開(kāi)發(fā)，會(huì)是怎樣的場(chǎng)面。