通常我們的團隊中，開發人員在Java語言層面具備相當的技術素養，經驗豐富，而且有許多成熟的、合理的規約，類型繁多的代碼隱患檢查工具，甚至在團隊間還有計劃內的評審和飛檢。但前端的程式碼不似後台，就像一個沒人痛的孩子，不只容易被低估、被輕視，導致品質低劣、可維護性差，技能上，更缺少優秀的前端開發人員。
JavaScript是前台程式碼中重要組成部分，隨著版本的延續，產品越做越大，JavaScript層面的重構，需要在整個過程中逐步強化。
當程式碼量達到一定程度，JavaScript最好能夠與頁面模組元件（例如自訂的FreeMarker標籤）一起被模組化。
模組化帶來的最大好處就是獨立性和可維護性，不用在海量的js中定位問題位置，簡單了，也就更容易被理解和接受，更容易被定制。
模組之間的依賴關係最好能夠保持簡單，例如有一個common.js，成為最通用的函數型程式碼，不包含或包含統一管理的全域變量，要求其可以獨立發布，其他元件js可以輕鬆地依賴它。舉個例子，我們常常需要對字串實作一個trim方法，可是js本身是不具備的，那麼就可以在這個common.js中擴展string的prototype來實現，這對外部的使用者是透明的。
使用命名空間是保持js互不干擾的一個好辦法，js講究起面向對象，就必須遵循封裝、繼承和多態的原則。
參考Java import的用法，我希望命名空間能帶來這樣的效果，看一個最簡單的實例吧：
我有一個模組play，其中包含了一個方法webOnlinePlay，那麼在沒有import這個模組的時候，我希望是js的執行是錯誤的：
Java代碼
webOnlinePlay(); //Error!無法找到方法
但是如果我引入了這個模組：
Java代碼
import("play"); ; //正確，能夠找到方法
其實實現這樣的效果也很簡單，因為預設呼叫一個方法webOnlinePlay()的實質是：window.webOnlinePlay()，對嗎？
所以在import("play")的時候，內部實作機制如下：
Java程式碼
var module = new playModule();
對於這個模組中的每一個方法，都導入到window物件上面，以直接使用：
Java程式碼
window[methodName] = module[methodName];
其實這裡並沒有什麼玄機，但是這種即需即取的思想卻為前端重構帶來了一個思路，一個封裝帶來的可維護性增強的思路，不是嗎？
聰明的你也許還會提到一個問題：
如果我沒有import這個play模組，這個頁面都不需要，那我能否連這個play.js都不載呢？
當然可以，請關注後面的分解——關於js的動態載入的部分。
