說起模組化，也許我們首先想到的是程式設計中的模組設計，以功能塊為單位進行程式設計，最後通過模組的選擇和組合構成最終產品。把這種思想運用到頁面構建中，也已經不是什麼新鮮事。相信很大一部分頁面構建工程師都經歷了這樣幾個階段：第一階段是在乙個css檔案中把多個頁面按自己的習慣順序從上往下編寫樣式，基本不考慮有無公用樣式，以完成設計呈現為首要目的；第二階段是提取不同頁面中的通用樣式，如公用顏色、圖示、按鈕等，實現一些基本元素的復用；第三階段是提取公用功能模組，如導航、版權資訊等，實現部分公用模組的復用。
剛才描述的第三階段的方法已經包含了模組化思想，不少團隊也都有一套成熟的模組化開發方案。而我第一次聽說模組化構建方式，是三年前在一家南韓網際網路企業工作時，某些產品中要求使用一種稱為uio方式，模組化通用的功能模組或元件，以達到最大程度的模組獨立性與復用性，當時團隊中很多同事和我一樣，認為這種工作方式約束了編碼的自由性，過多的結構約束反而降低了工作效率，加之產品之間也存在不統一，最後並沒有運用到整個團隊。
那麼，如果我們運用模組化構建的方式，優勢在哪呢？也許在開始嘗試之處，需要乙個適應的過程，可能會使團隊成員出現之前類似我當時的想法，但當大家都適應並熟練這種工作方式之後，必定能極大地提高頁面構建的效率。
假設有這樣乙個場景，團隊接到乙個頁面非常多、工作量非常大的緊急專案，第乙個團隊這麼做：組長給每人分配幾個頁面，大家分頭做完各自的頁面，統一交付，對於不同頁面之間結構呈現相似的模組，細心點的團隊可能會約定讓某個人寫好，再複製給每個需要用到的人，不太在意的，則讓每個人把各自頁面上的所有內容都寫一遍，已完成任務為重。第二個團隊事先根據所有的頁面劃分公用或重複模組，再按模組唯一性分配給每個人，有人負責搭建框架，有人製作模組，最後合併框架和模組，再按開發的工作計畫，順序交付頁面。對比的結果是，由於第二個團隊是多人共同製作乙個頁面，他們能以最快的速度產出開發需要的第一頁面，而且越到後期越能發現頁面中可重用的模組越多，最後整個工作時間也許能比第乙個團隊縮減一半。模組的復用不單是對本團隊的工作時間有很大影響，同樣，對於下游的開發者來說，意味著他們也不需要為相同的模組重套**或重新開發。此外，**的冗餘量、以及產品公升級時兩種工作方式的**擴充套件性也體現出很大的差距。再者，如果你的團隊將要運用bigpipe或者less的開發方式，css的模組化是最好的配合手段，或者說是必須的。
當決定使用模組化構建的工作方式時，遵循某些原則對模組化的順利推進有很大的幫助。
曾經有一篇關於物件導向css的文章中指出，物件導向的css有兩個主要原則：separate the structure from the skin，separate the container from the content。第乙個原則體現在模組化思想可以理解為，模組的設計製作和布局框架本身相分離，意味著你的模組不能只為某個布局而編寫樣式，像微博這類存在換膚功能的產品更是如此，如果模組在不同的**樣式下需要另寫很多樣式甚至是修改結構的時候，這個模組的製作就是失敗的；第二個原則說的布局與內容的分離，布局中某個位置不必只能放置某種內容，反過來可以理解為模組的靈活性和復用性。
其次遵守團隊協作開發規範原則。這個規範可以包含檔案目錄結構、檔案和樣式命名規範、sprite規範、模組劃分和呼叫規範等，例如我們對檔案目錄深度的規定、公用樣式使用規定、模組的樣式名唯一性規定、模組檔名和樣式名必須一致的規定等等，確保所有人產出的模組是統
一、規範的。
按結構呈現形式劃分模組的原則。這一點和模組化程式設計有較大的區別，通常在程式設計開發時是以模組的功能來劃分的，而在頁面構建上，有時候不同功能的模組呈現的樣式是一樣的，為達到模組樣式最大程度的復用，就不能按功能來劃分模組，簡單來說，哪些模組外觀結構一樣，我們就可以把它們歸為乙個模組，以微博右側模組舉例，「可能感興趣的人」和「推薦應用」模組的外觀是一樣，都是左側乙個、右側文字和功能按鈕，那它們就是同乙個樣式模組。
模組穩固性原則。我經常問新人乙個問題，「你覺得怎樣體現你寫的**質量高，比一般人好？」，大多數人會回答遵守語義化，減小不必要的巢狀，**盡量精簡。語義化和**精簡固然是評價質量的乙個重要方面，但是我認為，**是否考慮到資料遍歷的合理性，是否考慮到dom節點的可操作性，是否考慮到因擴充套件造成的抗破壞行，更能體現乙個頁面構建工程師的水平。
模組自適應性原則。指的是任何乙個模組，都盡可能實現寬度和高度的自適應，非特殊情況不要設定模組的寬高，採取這種原則製作出的模組具有很好的即插即用功能，是高效完成頁面拼合工作的重要前提。試想如果每個模組都定義了寬度，那麼在不同的布局上你就必須重新定義每個模組的寬高或邊距等屬性來適應當前布局。
margin-bottom原則。一般情況下，網頁的布局都是從上到下的流式布局（多欄結構也可以看成各欄內的流式布局），所以，我們可以為每個模組統一預設margin-bottom，達到統一間距的目的，避免出現有些模組設定上邊距、有些模組設定下邊距的情況發生。（左右間距通常是由布局框架的樣式設定）
在制訂好團隊的合作規範、遵守的原則後，並不代表你就可以完全按你的思路啟動工作，團隊配合是多向的，除了團隊內部，其他團隊的支援也是不可或缺的，所以還需要以下兩個前置條件：
設計必須嚴格遵循柵格化。模組是獨立的，但最終模組還是巢狀在布局中，因為我們的最終產出物是完整的靜態頁面，如何將分離的模組在最短的時間內，拼成乙個符合設計師意圖和產品要求的頁面？柵格化是快捷的保障，在乙個嚴格按照柵格化設計的布局框架中，工程師只需要設定好布局框架樣式和分欄的內外間距，後續的工作只需要把該頁面所使用的模組巢狀進來，再呼叫對應模組的樣式，由於模組的自適應性，在所有模組準備充分的情況下，通常乙個頁面的拼合只需要幾分鐘的時間。
產品、設計與互動的規範統一。通常在專案的某個階段，產品和設計在模組上的統一是比較容易的，但如果在同乙個專案的不同階段，尤其是在不同專案之間或不同產品之間要達到規範統一，就不是一件簡單的事情。當規範統一性出現問題時，導致模組化只停留在某個專案階段，每次新增新功能、增加新內容都需要增加全新的模組樣式，移植性和復用性大打折扣，無法發揮應有的效果。當然，產品是持續改變和創新的，我們不能要求乙個產品永遠按照某個規範來進行設計，但我們還是應該共同努力尋求階段性共贏的解決方案。在微博，經過各方長時間的努力，特別是互動設計對產品功能元件的統一，構建的wdl規範庫對我們的模組化提供了很大幫助。
根據實際情況來看，要達到所有滿足的條件往往不是一帆風順的，特別是第二個條件的達成。但是退一步來說，即使不能使模組化在每個專案、每個產品中長期穩定的發揮它的最大能量，至少可以在每一次專案任務中獲得模組化給團隊帶來的效率提公升。
如果經過大家的努力，在所有條件都滿足，而且模組化工作方式能在團隊順利開展的情況下，我們依然可能會遇到各式各樣的問題，乙個無法避免的問題就是 —— 產品功能公升級引起的模組變化，這時候是修改原有的模組還是另起乙個新的模組？二是模組的劃分程度，有些時候從模組的呈現和功能劃分都比較模糊，有些時候對某些內容是否劃為公用樣式還是模組、還是頁面獨有內容都是見仁見智的；三是模組的分類，採取何種方式分類便於查詢？類似這些問題還有很多，在不同的專案和形勢下，需要具體問題具體分析，發揮團隊的智慧型，尋找最合理的應對方案。
雖然在實施過程中可能會遇到各種問題和團隊配合之間的阻力，但是當你逐漸適應這種模組化團隊構建的工作方式時，你會愛上它！而當你的團隊高效地完成每個工作的時候，人們也會愛上你的團隊！
前端模組化
前端模組化解決什麼問題？有了模組，我就可以很方便的使用別人的 想要什麼功能，就用載入什麼模組。但是，這樣做需要有乙個前提，那就是大家必須以同樣的方式編寫模組，否則就亂套了。所以組內需要有一套統一的模組規範。如何實現模組？1 物件字面量的變體 2 js設計模式的模組模式 3 採用成熟的庫檔案。前兩種方...
前端模組化
定義 具有相同屬性和行為的事物的集合 在前端中 將一些屬性比較類似和行為比較類似的內容放在同乙個js檔案裡面，把這個js檔案稱為模組 目的 為了每個js檔案只關注與自身有關的事情，讓每個js檔案各行其職 模組化 指的就是遵守commonjs規範，解決不同js模組之間相互呼叫問題 commonjs a...
前端模組化
當多人開發同一專案時，很容易就會產生命名衝突的問題，尤其是js檔案，任何的js引入順序的打亂都可能導致專案執行失敗，為了解決命名衝突的問題，在es6之前，可以使用函式閉包來解決這個問題。即可能像這樣 function 這樣雖然可以解決命名衝突的問題，但也使得 的復用性變得極差，因為其它的檔案將無法再...