如何構建前端代碼

基本認識

開發環境和線上環境的區別

在好久之前，前端的部署其實比較簡單，開發環境下，靜態資源往服務器上面一扔就ok了，若是考慮下優化或者代碼保護，也只是加一個代碼壓縮和混淆。沒錯，剛入行的時候我就是這麼幹的。。。

可是隨着前端複雜度的發展，上面的作法已經沒法知足需求了，特別是AMD,CMD概念的引入，打包合併就變成一項基本工做了。

舉一個requirejs的例子，在一個複雜點的前端系統中，你能想象不打包直接上線嗎，那樣換來的可能就是打開首頁就須要download幾十個甚至上百個模塊資源，這種行爲是對網絡資源的一種無謂消耗。因此對應requirejs有個r.js，就是專門消滅這種無謂請求消耗的，它作的事情也比較簡單，按照必定規則，把各類模塊合併成一個，這樣在上線是一次請求就能download須要的全部js。

開發環境代碼和線上代碼區別

首先你們能夠在構建時取消相似壓縮，混淆這幾部，能夠觀察下，構建完成後的代碼，會和開發時你所寫的有差異，開發環境的代碼都通過了編譯處理，根據必定的規則從新編譯過。

舉一個例子，咱們在使用css3時，若是去本身寫樣式去適配chorme,safari,opera等等會累死。可是咱們按照一個規則寫一個，在構建時，代碼自動作補全，是否是就很方便，能提升很多效率。

再舉個例子，如今比較前沿的已經在開發環境下使用ES6了，可是想要在瀏覽器端直接運行還須要一段日子，可是沒事，咱們有Babel之類的工具，能夠在編譯時實現ES6到ES5的代碼轉換。這種用法我尚未用過，可是經過構建，咱們能夠用於嘗試一些新的東西。提早作一些技術積累。

前端工程化核心環節

從前面兩點你們應該能看出構建這一步的重要性了吧，能夠說須要作到前端工程化，提升開發效率等，構建編譯這一個步驟絕對是核心步驟之一。他的角色不遜色於搭建service，項目腳手架等等

具體舉例

百度前端不只有個fis（前端集成解決方案），還有一個edp，也是一個前端集成解決方法，主要是百度商業體系的前端在使用。
因爲咱們一直在使用edp，因此下面用edp舉例去了解下前端構建

下面介紹一下咱們本身系統中的一些使用

1. 首先是js模塊的合併，咱們會按照首屏加載和能夠懶加載的功能劃分，將模塊合併成總體，這樣就避免了散文件的出現。首先散文件是有害處的，第一是，散文件可能沒有版本號的區分，這樣由於緩存致使bug；第二是散文件會嚴重拖慢性能，由於不少散文件不只消耗請求資源，並且是在串行消耗。

2. 將js用到的模板的合併，目的也是減小無謂的請求。

3. 將less轉換成css進行合併

4. 將js文件壓縮處理

5. 將合併後的文件進行加上文件MD5版本號處理，MD5的目的就是基於文件內容解析出版本號，這樣若是某個模塊沒有變動過，能夠一直使用緩存，提升性能。

6. 將合併後而且包含MD5的文件的path更新到首頁html的require的config中

7. 修改文件引用對應的path，由於相似於js引用的模板和css都須要更新到打包合併的path上

8. 清理輸出時的無用文件

9. 添加版權信息等等

上面是一個基本流程，若是有特殊的需求，能夠繼續添加處理模塊。
例如想引入reactjs，若是是構建時打包的話，咱們確定不但願上線的代碼裏面有一個browser.min.js文件，這樣不只增長了靜態資源，並且增長了一個jsx翻譯處理。那麼咱們能夠在構建時增長一個jsx2js的步驟，這樣就達到了，開發使用jsx，可是發佈上線時，自動處理成了js代碼。

關於性能優化

這種構建處理，我理解出發點都是從性能角度考慮的。
對於一線的業務開發過程，咱們指望的是高效的開發業務，並不能把性能等等要求強加到業務開發中，否則咱們業務開發是低效的，並且，隨着性能優化策略的變動，咱們沒法隨意的在業務中修改代碼及時配合，就算是有人力修改，也可能致使bug。
因此將構建和業務解耦也是很關鍵的，只要業務開發符合某個規範，咱們能夠根據性能優化的點隨時更新優化策略，構建代碼的差異也是僅僅體如今性能上，而不會延生到業務中。

注意事項

你們能夠看看前面幾篇文章《如何避免工程效率陷阱》，《如何在大公司中成長》咱們在擁抱前端工程化時，不要停留在使用階段，也須要花點時間研究下原理，否則就很容易被工程了，由於你要相信將來前端的工程化只會讓你的業務開發更加簡單，關心的東西更少。

我的博客：http://tangguangyao.github.io/