JavaScript重構(一):模塊劃分和命名空間

通常我們的團隊中,開發人員在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(); //正確,能夠找到方法 
 
其實實現這樣的效果也很簡單,因為默認調用一個方法webOnlinePlay()的實質是:window.webOnlinePlay(),對嗎?
所以在import("play")的時候,內部實現機制如下:
Java代碼 
var module = new playModule(); 
 
對於這個模塊中的每一個方法,都導入到window對象上面,以直接使用:
Java代碼 
window[methodName] = module[methodName]; 
 
其實這裡並沒有什麼玄機,但是這種即需即取的思想卻給前端重構帶來瞭一個思路,一個封裝帶來的可維護性增強的思路,不是嗎?
 
聰明的你也許還會提到一個問題:
如果我沒有import這個play模塊,這個頁面都不需要,那我能否連這個play.js都不加載呢?
當然可以,請關註後面的分解——關於js的動態加載的部分。

作者“四火的BLOG”
 

You May Also Like