作為開發，不僅僅是前端，最佳化總是你繞不開的事，我們的目標就是要產品變得更快。最佳化的物件不僅僅指產品本身，還有我們日常的開發流程。從加入團隊 到現在，大概有一半左右的時間花在了最佳化上，期間遇到了很多問題，回過頭看，最佳化這件事情並不是那麼簡單，也是些很瑣碎的事情，要打造一個無痛的開發流 程，並且能夠相對輕鬆的對產品持續最佳化真的不輕鬆。沒有銀彈，任何專案都要花很多時間和精力。但任何值得改善的地方能夠有所提升都讓我們覺得努力沒白費。 有時候只想懶一點，從枯燥的重複中解放出來。
剛進來時，加上我團隊中一共3個人專職前端開發。專案比較簡單，前人已經做好了模組化，只是覺 得還不夠徹底。後來專案慢慢變得龐大，加上重構同學，人員最多的時候達到了13人。這個過程中遇到了很多問題，前端框架演變了三次，都是因為遇到了一些棘 手的問題，而不得已做出調整，沒有絕對的好壞，只有合不合適。
11.0時代
前期模組化已經做的不錯了，至少不必花大量時間去重構程式碼。模組劃分如下圖，邏輯層次上還是比較清晰。
前端模組化依賴的主流庫也就數國內的Seajs和國外的requirejs，這裡就不陳述。採用了Seajs作為模組管理器，zepto作為基礎庫檔案，lib主要包含了專案中用到的主流第三方庫檔案。
我們知道模組化帶來的最大弊端便是HTTP請求數增加，所以上線的時候必須合併檔案。下圖中的package模組是檔案大集合，打包了很多個JS模組，除去上圖中的基礎庫檔案和業務模組層，在上線的時候大部分檔案都被打包在package.js裡。
大部分頁面的JS請求是這樣的：
細心點的同學可能注意到兩個問題：檔案的大小和載入時間。剛才的截圖還是在PC端擷取的，手機和不同網路環境的表現會更加糟糕。
現在來看下目錄
存在的問題：
- 目錄看起來算規範，但實際上是公共的和業務的混在一塊。
- 大部分檔案合併在一個檔案，合併策略不合理。
- 由第二點引發的第三個問題，釋出上線時，只要兩人釋出涉及到package檔案，衝突必然發生。
- 釋出時需要down下上一次的檔案，對照合併的新檔案，以免發錯。
- 注意，第四點是人工。一不小心發錯，或者把他人剛釋出的檔案覆蓋了，這種事情發生10+次。
- 只有一臺測試機器，測試環境經常覆蓋是常事。
- 版本控制問題，不以SVN為版本，而是預釋出機器上程式碼，管理混亂
不敢想象如果10+人的團隊一起在這種模式下開發，會是怎樣的場面。