如何構建前端代碼
基本認識
開發環境和線上環境的區別
在很久以前，前端的部署其實比較簡單，開發環境下，靜態資源往服務器上面一扔就ok了，如果考慮下優化或者代碼保護，也只是加一個代碼壓縮和混淆。沒錯，剛入行的時候我就是這么干的。。。
但是隨著前端復雜度的發展，上面的做法已經無法滿足需求了，特別是AMD,CMD概念的引入，打包合并就變成一項基本工作了。
舉一個requirejs的例子，在一個復雜點的前端系統中，你能想象不打包直接上線嗎，那樣換來的可能就是打開首頁就需要download幾十個甚至上百個模塊資源，這種行為是對網絡資源的一種無謂消耗。所以對應requirejs有個r.js，就是專門消滅這種無謂請求消耗的，它做的事情也比較簡單，按照一定規則，把各種模塊合并成一個，這樣在上線是一次請求就能download需要的所有js。
開發環境代碼和線上代碼區別
首先大家可以在構建時取消類似壓縮，混淆這幾部，可以觀察下，構建完成后的代碼，會和開發時你所寫的有差別，開發環境的代碼都經過了編譯處理，根據一定的規則重新編譯過。
舉一個例子，我們在使用css3時，如果去自己寫樣式去適配chorme,safari,opera等等會累死。但是我們按照一個規則寫一個，在構建時，代碼自動做補全，是不是就很方便，能提高不少效率。
再舉個例子，現在比較前沿的已經在開發環境下使用ES6了，但是想要在瀏覽器端直接運行還需要一段日子，但是沒事，我們有Babel之類的工具，可以在編譯時實現ES6到ES5的代碼轉換。這種用法我還沒有用過，但是通過構建，我們可以用于嘗試一些新的東西。提前做一些技術積累。
前端工程化核心環節
從前面兩點大家應該能看出構建這一步的重要性了吧，可以說需要做到前端工程化，提高開發效率等，構建編譯這一個步驟絕對是核心步驟之一。他的角色不遜色于搭建service，項目腳手架等等
具體舉例
百度前端不僅有個fis（前端集成解決方案），還有一個edp，也是一個前端集成解決方法，主要是百度商業體系的前端在使用。由于我們一直在使用edp，所以下面用edp舉例去了解下前端構建
下面介紹一下我們自己系統中的一些使用
-
首先是js模塊的合并，我們會按照首屏加載和可以懶加載的功能劃分，將模塊合并成整體，這樣就避免了散文件的出現。首先散文件是有害處的，第一是，散文件可能沒有版本號的區分，這樣因為緩存導致bug；第二是散文件會嚴重拖慢性能，因為很多散文件不僅消耗請求資源，而且是在串行消耗。
-
將js用到的模板的合并，目的也是減少無謂的請求。
-
將less轉換成css進行合并
-
將js文件壓縮處理
-
將合并后的文件進行加上文件MD5版本號處理，MD5的目的就是基于文件內容解析出版本號，這樣如果某個模塊沒有變更過，可以一直使用緩存，提高性能。
-
將合并后并且包含MD5的文件的path更新到首頁html的require的config中
-
修改文件引用對應的path，因為類似于js引用的模板和css都需要更新到打包合并的path上
-
清理輸出時的無用文件
-
添加版權信息等等
上面是一個基本流程，如果有特殊的需求，可以繼續添加處理模塊。例如想引入reactjs，如果是構建時打包的話，我們肯定不希望上線的代碼里面有一個browser.min.js文件，這樣不僅增加了靜態資源，而且增加了一個jsx翻譯處理。那么我們可以在構建時增加一個jsx2js的步驟，這樣就達到了，開發使用jsx，但是發布上線時，自動處理成了js代碼。
關于性能優化
這種構建處理，我理解出發點都是從性能角度考慮的。
對于一線的業務開發過程，我們期望的是高效的開發業務，并不能把性能等等要求強加到業務開發中，不然我們業務開發是低效的，而且，隨著性能優化策略的變更，我們無法隨意的在業務中修改代碼及時配合，就算是有人力修改，也可能導致bug。
所以將構建和業務解耦也是很關鍵的，只要業務開發符合某個規范，我們可以根據性能優化的點隨時更新優化策略，構建代碼的差別也是僅僅體現在性能上，而不會延生到業務中。
注意事項
大家可以看看前面幾篇文章《如何避免工程效率陷阱》，《如何在大公司中成長》我們在擁抱前端工程化時，不要停留在使用階段，也需要花點時間研究下原理，不然就很容易被工程了，因為你要相信未來前端的工程化只會讓你的業務開發更加簡單，關心的東西更少。