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

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

11.0時(shí)代

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

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

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

大部分頁面的JS請求是這樣的：

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

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

存在的問題：

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

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

標(biāo)簽： 性能優(yōu)化 網(wǎng)站優(yōu)化 網(wǎng)站代碼優(yōu)化 

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點(diǎn)！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請與原作者聯(lián)系。