前端這幾年發展太快了，我學習的速度都跟不上這速度了。在JavaScript發展初期就是為了實現簡單的頁面交互邏輯，隨著前端的業務邏輯越復雜，代碼也越來越多，JavaScript極其簡單的代碼組織規范不足以駕馭如此龐大規模的代碼，于是一些問題就暴漏了出來。

?

1、命名沖突

我們平時做的項目的時候，都是會將一些通用的、底層的功能抽象出來，獨立成一個函數以提高代碼的可復用性，比如這樣子

function floatAdd(a,b) {// …… };

完了之后，放在public.js里面，讓其他有需要的同事調用就可以了。

不久之后，項目需求越來越多，新項目也一個接一個，換了個人來接手這個項目。新來的小哥開開心心的寫完新需求功能提交給測試，測試過來說，這地方不對啊。小哥就懵逼了，我沒動過這里啊，為啥就出錯了呢？經過一番排查，原來小哥也定義了一個floatAdd函數，把上面的給覆蓋了導致之前用過floatAdd函數的地方都出錯了。此時小哥的內心是奔潰的，因為他很多文件很多地方都有用到他自己定義的floatAdd函數，得挨個文件挨個地方的改。

為了降低沖突的概覽，大家開會討論后，決定把自己寫的公共函數封裝在一個對象中，看下面的代碼：

var myModule = {};myModule.floatAdd = function(a,b){// …… }

但是，公司這么多研發人員，總有那么一個會跟你的想法一樣，起了一個跟你一樣的對象名，所以命名空間依然有可能會沖突。那么為了繼續降低沖突概率，只好拉長命名空間，比如

project.tools.moduleA.floatAdd = xxx;

Yahoo的YUI早期就是這么做的，調用的時候還得這么寫：

project.tools.moduleA.floatAdd();

平時任務這么多，還得記住這么長的名字，記起來困難，一點也不優雅啊。所以這種方式并沒有被很多人采用，YUI后來也不用這種方式了。

?

2、文件依賴

項目中有個日期操作的功能，剛剛好不久前在開源社區看到一個合適的插件，然后就運用到當前項目中了。使用的時候引入插件，如下

<script type="text/javascript" src="js/lib/date.js"></script><script type="text/javascript" src="js/b.js"></script>

看著沒毛病是吧，然而報錯了。跑去看了一下文檔，原來這個插件是基于jQuery的，而頁面中沒有引入jQuery.js ，趕緊在插件date之前引入jQuery，還特地在插件隔壁備注了是依賴jQuery的，如下

<script type="text/javascript" src="js/lib/jQuery.js"></script><script type="text/javascript" src="js/lib/date.js"></script><!—依賴jQuery--><script type="text/javascript" src="js/b.js"></script>

過了一段時間，取消了這個功能，得把這些沒有必要的js文件去掉引用，直接把插件date跟依賴文件jQuery刪了。刷新頁面，報錯了。一番排查，發現原來另一個小哥寫的那部分功能有用到jQuery，趕緊又引用回來了。引用順序不能錯，也不能漏寫某個，在多人開發的時候是很難協調。后期優化重構都得小心翼翼，生怕一個不小心改了不該改的，刪了不該刪的。相信不少人都有碰到過上面的這種事，改來改去心好累啊，心疼自己。

命名沖突和文件依賴，是前端開發過程中的兩個經典問題。在這個無模塊的時代，大牛們也嘗試過了諸多方法，比如用函數來包裝代碼、java風格的命名空間，但并未解決根本問題。為了解決這些問題，js模塊化被提上了日程，開始了一段艱辛的歷程。

本文由一些歷史問題，拋出Js模塊化這個概念，接下的文章將逐步講述js模塊化的演進。

?

轉載于:https://www.cnblogs.com/huiguo/p/7967168.html

總結

以上是生活随笔為你收集整理的前端模块化（一）：模块化那些事儿的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。