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

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

11.0時代

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

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

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

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

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

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

存在的問題：

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

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

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

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