曾經(jīng)有一篇對于面向?qū)ο骳ss的文章中指出，面向?qū)ο蟮腸ss有兩個重要原則：separate the structure from the skin，separate the container from the content。第一個原則體當初模塊化思惟可以理解為，模塊的設計制作和布局框架自身相分別，意味著你的模塊不能只為某個布局而編寫樣式，像微博這類存在換膚功能的產(chǎn)品更是如斯，如果模塊在不同的皮膚樣式下需要另寫良多樣式甚至是修正結(jié)構的時候，這個模塊的制作就是失敗的;第二個原則說的布局與內(nèi)容的分離，布局中某個地位不用只能放置某種內(nèi)容，反過來可以懂得為模塊的機動性和復用性。

　　固然在實行進程中可能會碰到各種問題和團隊配合之間的阻力，然而當你逐步適應這種模塊化團隊構建的工作方式時，你會愛上它!而當你的團隊高效地完成每個工作的時候，人們也會愛上你的團隊,成都企業(yè)網(wǎng)站建設!

　　設計必須嚴格遵循柵格化。模塊是獨破的，但最終模塊還是嵌套在布局中,成都最大的網(wǎng)站建設公司，由于我們的最終產(chǎn)出物是完全的靜態(tài)頁面，如何將分離的模塊在最短的時間內(nèi)，拼成一個合乎設計師用意和產(chǎn)品要求的頁面?柵格化是快捷的保障，在一個嚴厲按照柵格化設計的布局框架中，工程師只需要設置好布局框架樣式和分欄的內(nèi)外間距，后續(xù)的工作只需要把該頁面所使用的模塊嵌套進來，再調(diào)用對應模塊的樣式，因為模塊的自適應性，在所有模塊籌備充足的情況下，通常一個頁面的拼合只要要幾分鐘的時間。

　　按結(jié)構呈現(xiàn)情勢劃分模塊的原則。這一點和模塊化編程有較大的差別，通常在編程開發(fā)時是以模塊的功能來劃分的，而在頁面構建上，有時候不同功能的模塊呈現(xiàn)的樣式是一樣的，為達到模塊樣式最大程度的復用，就不能按功能來劃分模塊，簡單來說，哪些模塊外觀結(jié)構一樣，我們就可以把它們歸為一個模塊，以微博右側(cè)模塊舉例，“可能感興致的人”和“推舉利用”模塊的外觀是一樣，都是左側(cè)一個圖片、右側(cè)文字和功能按鈕，那它們就是同一個樣式模塊。

　　Margin-bottom準則。個別情況下，網(wǎng)頁的布局都是從上到下的流式布局(多欄結(jié)構也能夠看成各欄內(nèi)的流式布局)，所以，我們可認為每個模塊統(tǒng)一預設margin-bottom，到達統(tǒng)一間距的目的，防止呈現(xiàn)有些模塊設置上邊距、有些模塊設置下邊距的情形產(chǎn)生。(左右間距通常是由布局框架的樣式設置)

　　方才描寫的第三階段的方式已經(jīng)包含了模塊化思想，不少團隊也都有一套成熟的模塊化開發(fā)方案。而我第一次據(jù)說模塊化構建方式，是三年前在一家韓國互聯(lián)網(wǎng)企業(yè)工作時，某些產(chǎn)品中要求使用一種稱為UIO方式，模塊化通用的功能模塊或組件，以達到最大程度的模塊獨立性與復用性，當時團隊中很多共事和我一樣，認為這種工作方式約束了編碼的自在性，過多的結(jié)構束縛反而下降了工作效率，加之產(chǎn)品之間也存在不統(tǒng)一，最后并不運用到整個團隊。

　　(微博UDC原創(chuàng)博文，歡送轉(zhuǎn)載并注明出處，歡迎訂閱 )

　　模塊牢固性原則。我常常問新人一個問題，“你感到怎么體現(xiàn)你寫的代碼品質(zhì)高，比普通人好?”，大多數(shù)人會答復遵照語義化，減小不必要的嵌套，代碼盡量精簡。語義化和代碼精簡誠然是評估質(zhì)量的一個重要方面，但是我以為，代碼是否考慮到數(shù)據(jù)遍歷的合感性，是否考慮到dom節(jié)點的可操作性，是否考慮到因擴展造成的抗損壞行，更能體現(xiàn)一個頁面構建工程師的程度。

　　那么，如果我們運用模塊化構建的方式，上風在哪呢?也許在開端嘗試之處，需要一個適應的過程，可能會使團隊成員出現(xiàn)之前類似我當時的主意，但當大家都適應并純熟這種工作方式之后，一定能極大地提供頁面構建的效率,成都網(wǎng)站建設工作室。

　　根據(jù)實際情況來看，要達到所有滿意的條件往往不是一路順風的，特別是第二個前提的達成。但是退一步來說，即便不能使模塊化在每個項目、每個產(chǎn)品中長期穩(wěn)固的發(fā)揮它的最大能量，至少可以在每一次項目任務中取得模塊化給團隊帶來的效力晉升。

　　如果經(jīng)過大家的努力，在所有條件都知足，而且模塊化工作方式能在團隊順利發(fā)展的情況下，我們?nèi)匀豢赡軙�遇到各式各樣的問題，一個無法避免的問題就是，產(chǎn)品功能升級引起的模塊變更，這時候是修改原有的模塊還是另起一個新的模塊?二是模塊的劃分水平，有些時候從模塊的呈現(xiàn)和功能劃分都比較含混，有些時候?qū)δ承﹥?nèi)容是否劃為公用樣式還是模塊、還是頁面獨占內(nèi)容都是見仁見智的;三是模塊的分類，采取何種方式分類便于查找?相似這些問題還有許多，在不同的項目和局勢下，需要詳細問題詳細剖析，發(fā)揮團隊的智慧，尋找最公道的應答方案。

　　當決議應用模塊化構建的工作方式時，遵守某些原則對模塊化的順利推動有很大的輔助。

　　在制定好團隊的配合規(guī)范、遵守的原則后，并不代表你就可以完整按你的思路啟動工作，團隊配合是多向的，除了團隊內(nèi)部，其余團隊的支撐也是不可或缺的，所以還需要以下兩個前置條件：

　　說起模塊化，興許咱們首先想到的是編程中的模塊設計，以功效塊為單位進行程序設計，最后通過模塊的抉擇跟組合形成終極產(chǎn)品。把這種思維應用到頁面構建中，也已經(jīng)不是什么新穎事。信任很大一局部頁面構建工程師都閱歷了這樣多少個階段：第一階段是在一個css文件中把多個頁面按本人的習慣次序從上往下編寫款式，根本不斟酌有無公用樣式，以實現(xiàn)設計浮現(xiàn)為重要目標;第二階段是提取不同頁面中的通用樣式，如公用色彩、圖標、按鈕等，實現(xiàn)一些基礎元素的復用;第三階段是提取公用功能模塊，如導航、版權信息等，實現(xiàn)部門公用模塊的復用。

　　模塊自適應性原則。指的是任何一個模塊，都盡可能實現(xiàn)寬度和高度的自適應，非特別情況不要設置模塊的寬高，采用這種原則制作出的模塊存在很好的即插即用功能，是高效完成頁面拼合工作的主要條件。試想如果每個模塊都定義了寬度，那么在不同的布局上你就必須重新定義每個模塊的寬高或邊距等屬性來適應該前布局。

　　假設有這樣一個場景，團隊接到一個頁面十分多、工作量無比大的緊迫名目，第一個團隊這么做：組長給每人分配幾個頁面，大家分頭做完各自的頁面，同一交付，對于不同頁面之間構造出現(xiàn)類似的模塊，仔細點的團隊可能會商定讓某個人寫好，再復制給每個需要用到的人，不太在意的，則讓每個人把各自頁面上的所有內(nèi)容都寫一遍，已完成義務為重。第二個團隊當時依據(jù)所有的頁面劃分公用或反復模塊，再按模塊獨一性調(diào)配給每個人，有人負責搭建框架，有人制作模塊，最后合并框架和模塊，再按開發(fā)的工作打算，順序交付頁面。對照的成果是，因為第二個團隊是多人獨特制造一個頁面，他們能以最快的速度產(chǎn)出開發(fā)需要的第一頁面，而且越到后期越能發(fā)明頁面中可重用的模塊越多，最后全部工作時光也許能比第一個團隊縮減一半。模塊的復用不單是對本團隊的工作時間有很大影響，同樣，對下游的開發(fā)者來說，象征著他們也不須要為雷同的模塊重套代碼或從新開發(fā)。此外，代碼的冗余量、以及產(chǎn)品進級時兩種工作方式的代碼擴大性也體現(xiàn)出很大的差距。再者，假如你的團隊將要運用BIGPIPE或者LESS的開發(fā)方法，css的模塊化是最好的配合手腕，或者說是必需的。

　　產(chǎn)品、設計與交互的標準統(tǒng)一。通常在項目的某個階段，產(chǎn)品和設計在模塊上的統(tǒng)一是比擬輕易的，但如果在統(tǒng)一個項目的不同階段，尤其是在不同項目之間或不同產(chǎn)品之間要達到規(guī)范統(tǒng)一，就不是一件簡略的事件。當規(guī)范統(tǒng)一性涌現(xiàn)問題時，導致模塊化只停留在某個項目階段，每次增加新功能、增添新內(nèi)容都需要增長全新的模塊樣式，移植性和復用性大打折扣，無奈施展應有的后果。當然，產(chǎn)品是連續(xù)轉(zhuǎn)變和翻新的，我們不能請求一個產(chǎn)品永遠依照某個規(guī)范來進行設計，但我們?nèi)允菓�當共同盡力追求階段性共贏的解決計劃。在微博，經(jīng)由各方長時間的努力，特殊是交互設計對產(chǎn)品功能組件的統(tǒng)一，構建的WDL規(guī)范庫對我們的模塊化供給了很大贊助。

　　其次遵守團隊合作開發(fā)規(guī)范原則。這個規(guī)范可以包括文件目錄結(jié)構、文件和樣式命名規(guī)范、圖片sprite規(guī)范、模塊劃分和調(diào)用規(guī)范等，例如我們對文件目錄深度的規(guī)定、公用樣式使用劃定、模塊的樣式名唯一性規(guī)定、模塊文件名和樣式名必須一致的規(guī)定等等，確保所有人產(chǎn)出的模塊是統(tǒng)一、規(guī)范的。