寫在前面：
面試時常被問到，你知道什麼是模組化開發嗎？模組化開發能帶來什麼好處？
下面的內容可以幫助你簡單了解什麼是模組化開發，從對它模糊的印象中看到一些清晰的輪廓，幫助你了解模組化開發的現狀，以對選擇哪種模組化開發有個選擇的方向。
目錄：
什麼是模組化開發
模組化開發的意義：
模組化開發的好處：
（1）避免變數汙染，命名衝突
（2）提高**復用率
（3）提高了可維護性
（4）方便依賴關係管理
想必有一定開發經驗的同學，對模組化開發的定義及優點，都很清晰了。那麼不了解的同學也不必著急，我們可以把這些優點當做疑問，當這些疑問被驗證之後，就知道上述結論是否正確了。
模組化開發的歷史進展(基於es5)：
最初接觸js**的時候，都是散亂的，按需定義變數，使用語法，來實現自己的功能。
在工作中發現，我們這麼寫，會寫很多重複的**，那這些重複的**是不是可以提煉出來復用呢？於是就有了函式的封裝，這大概就是模組化開發最原始的樣子。
有了函式的封裝，大大提高了**的復用性。但是變數的命名成了乙個跟給孩子起名一樣的歷史難題。功能越多，命名衝突的問題越明顯。於是簡單的物件封裝出現了，勞動人民的 智慧型總是無窮無盡的。命名衝突的問題立即得到了緩解。
但是下乙個問題馬上就來了，簡單的物件封裝，不能保證物件內部的變數是私有的。通過物件的封裝，可以將乙個頁面或者專案，拆解成幾個部分，但是隨著專案的擴充套件，這拆解出來的『模組』，並看不出明顯的依賴關係，冗雜在乙個檔案中管理，維護、修改的時候很麻煩，修改一處，需要在檔案中全域性審查，何處定義，何處呼叫。
iife解決了這個問題，我們可以把拆出來的功能模組，單獨寫在乙個js檔案中，這樣修改起來就方便多了，再也不用在大篇幅不相干的**中去尋覓我需要的那部分了。可是網際網路的發展，使用者的需求提高。我們的問題又來了，js檔案維護模組，導致乙個頁面需要載入多個js檔案，js檔案的載入會阻塞dom渲染，那麼js檔案越多，頁面白屏的時間就越長，使用者的體驗就越差。
因此模組化開發規範應運而生，瀏覽器遵循模組化規範，研發使用既定的方式去開發模組。前端的發展又昇華了一步。
下面看圖結合簡單的案例，闡述了模組化開發的雛形階段：
模組化開發規範：
上面我們提到了模組化開發的應運而生，最初的模組化開發是commonjs規範，nodejs是commonjs的實現。
簡言之，commonjs之後的模組化規範，都是基於commonjs衍生而來的。
require.js、sea.js現在基本上都不用了，圖中講的載入特點，使用最新的規範，你會發現，require.js是按需載入，sea.js是依賴前置。雖然這幾個規範中都是使用require載入依賴項，但是對require的封裝是有差異的，因此才會產生同步載入、非同步載入的差異，感興趣的同學可以自己寫demo驗證一下。
es6規範，經過編譯之後，import會編譯成commonjs規範中的require,編譯後的依賴項頁都是前置的。
奉上我粗簡的demo：
模組化開發
講模組化開發之前，我們先了解一下 傳統開發模式 是什麼？比如說a所在的公司在做乙個專案，公司安排a跟b還有c三個人一起協同開發，a負責一部分功能塊，b負責另一部分功能塊，把專案的功能分成一塊一塊，這適用於多人協作開發，每個人負責不同的功能塊，當然，這其中有人是負責整合的，有人是負責開發公共功能塊的等...
模組化開發
commonjs規範 同步模式載入模組，導致效率低 node.js環境 乙個檔案就是乙個模組 每個模組都有單獨地作用域 通過module.exports匯出成員 通過require函式載入模組 amd asynchronous module definition 規範 使用相對複雜 模組js檔案請求...
模組化開發
模組化的提出 對於一些程式，函式組成少的時候，可以放在乙個原始檔中。如下面的 猜硬幣遊戲 只有4個函式組成 include include include using namespace std void prn instruction void play intget call from user...