摘要：　　什么是設(shè)計(jì)模式？　　曾有人調(diào)侃，設(shè)計(jì)模式是工程師用于跟別人顯擺的，顯得高大上；也曾有人這么說(shuō)，不是設(shè)計(jì)模式?jīng)]用，是你還沒(méi)有到能懂它，會(huì)用它的時(shí)候。　　先來(lái)看一下比較官方的解釋?zhuān)骸霸O(shè)計(jì)模式（Design pattern）是一套被反復(fù)使用、多數(shù)人知曉的、經(jīng)過(guò)分類(lèi)的、代碼設(shè)計(jì)經(jīng)驗(yàn)的總結(jié)。使用設(shè)計(jì)模式是為了可重用代碼、讓代碼更容易被他人理解、保證代碼可靠性。 毫無(wú)疑問(wèn)，設(shè)計(jì)模式于己于他人于系統(tǒng)都是多贏

　　什么是設(shè)計(jì)模式？

　　曾有人調(diào)侃，設(shè)計(jì)模式是工程師用于跟別人顯擺的，顯得高大上；也曾有人這么說(shuō)，不是設(shè)計(jì)模式?jīng)]用，是你還沒(méi)有到能懂它，會(huì)用它的時(shí)候。

　　先來(lái)看一下比較官方的解釋?zhuān)骸霸O(shè)計(jì)模式（Design pattern）是一套被反復(fù)使用、多數(shù)人知曉的、經(jīng)過(guò)分類(lèi)的、代碼設(shè)計(jì)經(jīng)驗(yàn)的總結(jié)。使用設(shè)計(jì)模式是為了可重用代碼、讓代碼更容易被他人理解、保證代碼可靠性。 毫無(wú)疑問(wèn)，設(shè)計(jì)模式于己于他人于系統(tǒng)都是多贏的；設(shè)計(jì)模式使代碼編制真正工程化；設(shè)計(jì)模式是軟件工程的基石脈絡(luò)，如同大廈的結(jié)構(gòu)一樣?！?/p>

　　今天我們來(lái)聊聊CSS的設(shè)計(jì)模式。

　　設(shè)計(jì)模式，這個(gè)詞匯我們常見(jiàn)，幾乎所有的編程語(yǔ)言都會(huì)有幾套，但深入研究的人不多，原因如下：

　　1、似乎沒(méi)有太大必要性去強(qiáng)調(diào)它，有問(wèn)題了改一下或者按團(tuán)隊(duì)規(guī)范來(lái)就行；

　　2、不去使用一些既有的模式也無(wú)傷大雅；

　　3、不少人所接觸的業(yè)務(wù)量級(jí)還沒(méi)有達(dá)到需要規(guī)劃和組織的程度，光寫(xiě)布局，寫(xiě)特效，照顧兼容，就夠喝一壺的了，沒(méi)有意識(shí)去思考一些方法論的問(wèn)題。

　　當(dāng)然，這三者都是我經(jīng)歷過(guò)的，相信你也是~

　　我們都會(huì)長(zhǎng)大，都會(huì)慢慢的做更多、更大、更復(fù)雜的項(xiàng)目，這個(gè)時(shí)候，就需要自上而下，全流程的去思考一些問(wèn)題。后臺(tái)不說(shuō)，只講前端，比如：風(fēng)格的制定、色調(diào)、模塊、布局方式、交互方式、邏輯等等，如果再加上團(tuán)隊(duì)合作，若再?zèng)]有一個(gè)規(guī)劃的話，要不了多久，那些看起來(lái)沒(méi)問(wèn)題的代碼，就會(huì)暴露出各種問(wèn)題，模塊命名、類(lèi)的命名、文件的組織、共用模塊的提取、代碼的復(fù)用、可讀性、擴(kuò)展性、維護(hù)性。它們看起來(lái)只是一些簡(jiǎn)單的小動(dòng)作，卻需要你看得更遠(yuǎn)，避免將來(lái)出問(wèn)題需要付出更大的代價(jià)，甚至被迫整個(gè)項(xiàng)目重構(gòu)，可謂，功在當(dāng)代，利在千秋~

　　既然要對(duì)CSS進(jìn)行設(shè)計(jì)，那么肯定是它本身存在一些問(wèn)題或者缺陷，其中，一個(gè)最明顯的就是，它的任何一個(gè)規(guī)則，都是全局性的聲明，會(huì)對(duì)引入它的頁(yè)面當(dāng)中所有相關(guān)元素起作用，不管那是不是你想要的。而獨(dú)立及可組合的模塊是一個(gè)可維護(hù)系統(tǒng)的關(guān)鍵所在。下面，我們就從多個(gè)層面來(lái)探討一下，到底該怎樣寫(xiě)CSS，才是更科學(xué)的。

　　從需求出發(fā)

　　分

　　我們剛開(kāi)始學(xué)習(xí)寫(xiě)字的時(shí)候，是不會(huì)去考慮，寫(xiě)出來(lái)的某句話好不好，文章結(jié)構(gòu)合適不合適，因?yàn)槲覀兪且庾R(shí)不到的。寫(xiě)代碼也一樣，剛開(kāi)始，我們只是去定義規(guī)則，能用對(duì)了屬性，語(yǔ)法正確，把頁(yè)面實(shí)現(xiàn)出來(lái)了，就好。慢慢地，就會(huì)發(fā)現(xiàn)，頁(yè)面也是有結(jié)構(gòu)的，我們按照頁(yè)面的結(jié)構(gòu)去組織代碼，會(huì)不會(huì)更好？比如，分成頭部、導(dǎo)航、側(cè)邊欄、banner區(qū)、主內(nèi)容區(qū)、底部等。

　　然而這樣貌似還是不夠，因?yàn)檫€有一些東西，復(fù)用度是很高的，又不好把它歸為任何一個(gè)固有模塊，比如：面包屑、分頁(yè)、彈窗等，它們不適合被放到某一個(gè)固有模塊的代碼中，就可以單獨(dú)的分出一段專(zhuān)屬的css和js，或許，這就是組件化的由來(lái)~

　　拆

　　在分了之后，我們的代碼看起來(lái)已經(jīng)比之前好很多了，組織清晰，維護(hù)性大幅提高，但是，好像還是不夠，我們會(huì)發(fā)現(xiàn)另外一些東西，很細(xì)小，但復(fù)用度也很高，它們同樣不適合被放到模塊中去，比如，邊框、背景、圖標(biāo)、字體、邊距、布局方式等等。如果我們?cè)诿總€(gè)需要它們的地方，都定義一次，它們會(huì)被重復(fù)很多次，顯然，這背離好的實(shí)踐，會(huì)造成代碼冗余和維護(hù)困難。所以，我們需要“拆”。拆過(guò)之后會(huì)怎樣？我們想在哪里用可以直接加，需要改的時(shí)候統(tǒng)一改。

　　排

　　經(jīng)過(guò)了“分”、“拆”，我們的代碼結(jié)構(gòu)已經(jīng)十分清晰，各個(gè)內(nèi)容模塊，功能模塊，UI模塊都乖巧的等待召喚，那么還差什么？是的，還差有序的組織，分類(lèi)清晰之后，還需要排列有序，從不同緯度去考量，我們總能精益求精。舉個(gè)栗子，我們可能會(huì)看到像這樣：

@import "mod_reset.css";
@import "ico_sprite.css";
@import "mod_btns.css";
@import "header.css";
@import "mod_tab.css";
@import "footer.css";

　　我們將不同的部分按照一定的順序去擺放，能讓我們的代碼看起來(lái)更加有序，易于維護(hù)，同時(shí)，有利于進(jìn)行繼承或?qū)盈B覆蓋。不要小看這一步，看似可有可無(wú)，實(shí)際要求比較高的統(tǒng)籌規(guī)劃能力，可以減少冗余代碼和快速定位問(wèn)題位置等。

　　除此之外，我們依然可以有其他的方法來(lái)幫助我們進(jìn)行區(qū)分代碼范圍，比如：

　　1、在文件頭部建立一個(gè)簡(jiǎn)要的目錄

　2、使用區(qū)塊注釋

　　在注釋中，應(yīng)該盡量詳細(xì)的寫(xiě)清楚該段代碼的目的，狀態(tài)切換，調(diào)整原因，交互邏輯等等，這樣不僅利于自己的維護(hù)，更加利于別人接手維護(hù)你的代碼。

　　從結(jié)論出發(fā)

　　除了需求當(dāng)中一些通用部分，另外一些也是需要注意，但不會(huì)被正式定義的東西，它們來(lái)源于我們的實(shí)踐經(jīng)驗(yàn)，比如：

　　層級(jí)嵌套不要太深

　　稍微了解一些瀏覽器渲染原理的都知道，它在解析CSS規(guī)則的時(shí)候，是從右向左，一層層的去遍歷尋找，如果層級(jí)太多，必然增加了渲染時(shí)間，影響渲染速度。另外，如果選擇器層級(jí)過(guò)多，也就間接反應(yīng)了，你的HTML結(jié)構(gòu)可能寫(xiě)得不夠簡(jiǎn)潔。

　　那么具體多少層合適？一般建議是不超過(guò)4層，但話又說(shuō)回來(lái)，超過(guò)4層會(huì)怎樣嗎？不會(huì)有多明顯的影響，除非你寫(xiě)到很恐怖的數(shù)量，或者項(xiàng)目極其龐雜，可能能看出來(lái)影響，其實(shí)從我們?nèi)粘Ｐ枨髞?lái)看，4層以?xún)?nèi)足可以解決絕大多數(shù)問(wèn)題，故而，是合理的。

　　避免使用元素選擇器

　　出于兩點(diǎn)考慮：

　　第一點(diǎn)，和上一段提到的相關(guān)，在HTML中，有很多常用的高頻元素，比如，div、p、span、a、ul等。如果，你在多層選擇器的最內(nèi)層使用了元素選擇器，那么，在開(kāi)始尋找時(shí)，瀏覽器就會(huì)遍歷HTML中的所有該元素，顯然，這是沒(méi)有必要的。

　　第二點(diǎn)，我們的需求和代碼結(jié)構(gòu)都是存在著潛在變化的，今天寫(xiě)好了一個(gè)頁(yè)面，明天可能就要再加進(jìn)去一個(gè)按鈕，再加進(jìn)去一句話，再加進(jìn)去一個(gè)圖標(biāo)。我們寫(xiě)好的一個(gè)結(jié)構(gòu)，也隨時(shí)可能被復(fù)用到別的結(jié)構(gòu)中去。所以，如果，你使用了元素選擇器去定死某個(gè)東西，不論是新加進(jìn)來(lái)的東西，還是被復(fù)用的東西加到別的結(jié)構(gòu)里去，都極有可能產(chǎn)生樣式的沖突，這個(gè)時(shí)候，你又不得不寫(xiě)多余的樣式進(jìn)行覆蓋修正，或者重新定義類(lèi)。

　　所以，出于以上考慮，在具體的代碼模塊中，盡量不要使用元素選擇器，使用元素選擇器的前提是，你完全的確定，不會(huì)導(dǎo)致出現(xiàn)問(wèn)題。注意，我用的限定范圍是“具體的代碼模塊”，那么用于定義通用規(guī)則的樣式，是可以的，也是推薦使用的，比如，reset。也可以是別的地方，這就需要我們自行考量。

　　避免使用群組選擇器

　　群組選擇器會(huì)有什么問(wèn)題？直接上圖吧。

　　圖中這種情況不多見(jiàn)，此處只是舉個(gè)例子，這里寫(xiě)了三組選擇器，用來(lái)定義不同地方的同一種樣式，其明顯的缺陷是，如果有第四個(gè)地方需要使用到，你不得不再往里加一組選擇器，如果有10個(gè)不同的地方，你就寫(xiě)10個(gè)？這對(duì)于維護(hù)來(lái)說(shuō)，是很痛苦的，聰明的我們，怎能被如此繁復(fù)又不必要的勞動(dòng)所困擾，故而，墻裂不推薦此種做法，完全可以提取出來(lái)一個(gè)公用類(lèi)，定義統(tǒng)一樣式，然后，哪里需要放哪里，復(fù)用和維護(hù)都會(huì)更加方便。

　　當(dāng)然，你可能會(huì)說(shuō)，我在寫(xiě)第一個(gè)的時(shí)候，不會(huì)知道后面還有那么多，有沒(méi)有必要提取是不知道的，是的，所以，需要你根據(jù)經(jīng)驗(yàn)去判斷，也需要在項(xiàng)目推進(jìn)過(guò)程中，適時(shí)的對(duì)代碼進(jìn)行整理和重構(gòu)。

　　文件引入的數(shù)量和順序

　　對(duì)于剛接觸網(wǎng)頁(yè)的朋友來(lái)說(shuō)，這兩點(diǎn)也是容易忽視的，因?yàn)樗鼈兛雌饋?lái)沒(méi)什么大影響，多幾次請(qǐng)求，樣式是否已經(jīng)加載，都沒(méi)那么容易把人逼瘋。但是出于對(duì)用戶(hù)體驗(yàn)的極致追求，我們還是希望文件請(qǐng)求次數(shù)盡量少，內(nèi)容的顯示有個(gè)優(yōu)先順序，文件加載有個(gè)先后順序。這樣，在實(shí)在難以縮減文件大小的時(shí)候，讓用戶(hù)先看到更重要的，正常展示的內(nèi)容。

　　以上只是幾點(diǎn)舉例，更多實(shí)戰(zhàn)結(jié)論，大家可以多讀相關(guān)的博文或者書(shū)籍，都會(huì)有前輩們的經(jīng)驗(yàn)之談。

　　從矛盾出發(fā)

　　通用和語(yǔ)義

Naming convention is beneficial for immediately understanding which category a particular style belongs to and its role within the overall scope of the page. On large projects, it is more likely to have styles broken up across multiple files. In these cases, naming convention also makes it easier to find which file a style belongs to.

　　命名規(guī)則有助于立即理解一個(gè)特定樣式屬于哪一類(lèi)，它在頁(yè)面的整體范圍內(nèi)的作用。在大型項(xiàng)目中，它更可能有在多個(gè)文件中被打破的樣式。在這種情況下，命名約定也可以更容易地找到一個(gè)樣式屬于哪個(gè)文件的文件。

　　很多時(shí)候，我們需要一個(gè)東西被定義為通用的，以便復(fù)用，比如：模塊標(biāo)題、按鈕、提示文字、圖標(biāo)等，最開(kāi)始的時(shí)候，我們習(xí)慣去看視覺(jué)稿的內(nèi)容，是“新聞”，我們就定義“news”，是“關(guān)于”，我們就定義“about”，是紅色的按鈕，我們就定義“red-btn”等，這樣會(huì)導(dǎo)致一個(gè)問(wèn)題，如果有另外一個(gè)跟新聞列表差不多的樣式和結(jié)構(gòu)，但不是新聞，怎么辦？繼續(xù)使用“news”顯然不合適，這就告訴我們，不能把目光局限于內(nèi)容，需要內(nèi)容和結(jié)構(gòu)分離。

　　不能用“news”了，那用什么呢？abc？123？這樣總不會(huì)沖突了吧，萬(wàn)事大吉~其實(shí)，這是走了另一個(gè)極端，這樣雖然在很大程度上避免了和別的模塊沖突，但其本身的可讀性就被大大降低了，別人，甚至你自己過(guò)一段時(shí)間都會(huì)忘記它是什么，對(duì)于團(tuán)隊(duì)合作是很不利的。至于需要用什么樣的命名方式，需要你根據(jù)項(xiàng)目的整體來(lái)進(jìn)行規(guī)劃，適合根據(jù)什么特點(diǎn)來(lái)區(qū)分與之不同的結(jié)構(gòu)，又能讓人比較容易的在名稱(chēng)和結(jié)構(gòu)之間建立聯(lián)系，比如所屬類(lèi)別、功能、頁(yè)面等。

　　團(tuán)隊(duì)和個(gè)人

　　一個(gè)團(tuán)隊(duì)當(dāng)中，大家的經(jīng)歷不同，編碼水平和習(xí)慣也不同，這樣就會(huì)造成，一個(gè)人一個(gè)寫(xiě)法，你用中劃線，我用下劃線；我用英文全拼，你用簡(jiǎn)寫(xiě)，等等。這些雖然沒(méi)有什么對(duì)錯(cuò)之分，但對(duì)于團(tuán)隊(duì)成員之間的協(xié)作造成了不小的障礙，別人必須花時(shí)間去適應(yīng)和讀懂你是怎樣組織和定義的，這就無(wú)形之中提高了成本。

　　所以，就有了“團(tuán)隊(duì)規(guī)范”存在的必要，規(guī)范除了一些寫(xiě)法上的規(guī)定，讓我們的代碼更加統(tǒng)一、清晰、可讀性更強(qiáng)、辨識(shí)度更高。還可以提取一些最佳實(shí)踐和復(fù)用模塊等，對(duì)于團(tuán)隊(duì)里每個(gè)人來(lái)說(shuō)，都是有好處的。

　　當(dāng)然，對(duì)于人來(lái)說(shuō)，最難的，莫過(guò)于調(diào)整既有的習(xí)慣，這就會(huì)有進(jìn)入一個(gè)團(tuán)隊(duì)之后“轉(zhuǎn)型”的陣痛，其實(shí)這種痛也是成長(zhǎng)的痛，你會(huì)學(xué)習(xí)到更好的編碼方式，更好的實(shí)踐方法，會(huì)從項(xiàng)目或者團(tuán)隊(duì)的整體去考量一件事的價(jià)值和意義。

　　CSS和預(yù)處理器

　　前面我有文章詳細(xì)的談過(guò)CSS預(yù)處理器，我曾經(jīng)對(duì)它也是排斥的，因?yàn)閷W(xué)習(xí)成本，因?yàn)橛X(jué)得應(yīng)用起來(lái)沒(méi)有必要?？墒且坏┠銢Q定去學(xué)習(xí)使用它，就會(huì)覺(jué)得不是那樣，預(yù)處理器在向你介紹它自己的時(shí)候，就有特意強(qiáng)調(diào)過(guò)，它的語(yǔ)法是和CSS完全兼容的，也就是說(shuō)，你在LESS或者SASS文件中，直接寫(xiě)CSS代碼是沒(méi)有問(wèn)題的。除此之外，它能給我們提供很多便利，比如定義統(tǒng)一的變量；使用嵌套而不用一直重復(fù)著寫(xiě)一些選擇器；可以提取公共的代碼塊然后很方便的復(fù)用等等。

　　故而，當(dāng)我們已經(jīng)把CSS組織和書(shū)寫(xiě)得很好了之后，預(yù)處理器，就是再次為我們插上一雙翅膀，能更靈活和高效的編碼。

　　從現(xiàn)有模式出發(fā)

　　再來(lái)簡(jiǎn)單看看一些廣為流傳的模式。（ps：先后順序與排名、好壞無(wú)關(guān)）

　　一、OOCSS——Object Oriented CSS

　　接觸過(guò)計(jì)算機(jī)的應(yīng)該都知道，OOP——Object Oriented Programming，如果你是第一次接觸OOCSS，你會(huì)很困惑，難道是“面向?qū)ο蟮腃SS”嗎？它不是一本真正的編程語(yǔ)言啊，如何面向?qū)ο螅?/p>

　　OOCSS，最早被提及，是在2009年，它的兩大原則是：

　　separating structure from skin and container from content.

　　直譯過(guò)來(lái)就是，結(jié)構(gòu)和皮膚分離，容器和內(nèi)容分離。

　　即不要把結(jié)構(gòu)和皮膚以及內(nèi)容進(jìn)行強(qiáng)耦合，而是相互獨(dú)立，所要達(dá)到的目標(biāo)是更易復(fù)用和組合，可以選擇使用，選擇引用等。

　　詳細(xì)了解鏈接：https://www.smashingmagazine.com/2011/12/an-introduction-to-object-oriented-css-oocss/

　　二、SMACSS——Scalable and Modular Architecture for CSS

　　從實(shí)踐上說(shuō)，OOCSS給出了一種值得借鑒的思想，但在代碼的組織方面，它并未給出具體的實(shí)施方法，從這一點(diǎn)上來(lái)說(shuō)，SMACSS更進(jìn)一步。

　　它的核心是：

　　1、Base（基礎(chǔ)）

　　基礎(chǔ)的樣式，就是一些需要最先定義好，針對(duì)于某一類(lèi)元素的通用固定樣式。

　　2、Layout（布局）

　　布局樣式，是跟頁(yè)面整體結(jié)構(gòu)相關(guān)，譬如，列表，主內(nèi)容，側(cè)邊欄的位置、寬高、布局方式等。

　　3、Module（模塊）

　　模塊樣式，就是我們?cè)趯?duì)頁(yè)面進(jìn)行拆的過(guò)程中，所抽取分類(lèi)的模塊，這類(lèi)的樣式分別寫(xiě)到一起。

　　4、State（狀態(tài)）

　　頁(yè)面中的某些元素會(huì)需要響應(yīng)不同的狀態(tài)，比如，可用、不可用、已用、過(guò)期、警告等等。將這類(lèi)樣式可以組織到一起。

　　5、Theme（主題）

　　主題是指版面整個(gè)的顏色、風(fēng)格之類(lèi)，一般網(wǎng)站不會(huì)有頻繁的較大的改動(dòng)，給我們印象比較深的是QQ空間，其他應(yīng)用的不是很多，所以，這個(gè)一般不會(huì)用到，但有這樣一個(gè)意識(shí)是好的，需要用到的時(shí)候，就知道該怎樣規(guī)劃。

　　有了以上5點(diǎn)分類(lèi)策略，我們的代碼組織起來(lái)，思路就會(huì)很清晰，會(huì)安排的很有序，另外的好處是，可以解決命名難和混亂，之所以有這個(gè)問(wèn)題，主因便是我們不知道以怎樣的標(biāo)準(zhǔn)去定義元素的所屬和特點(diǎn)，有了分類(lèi)之后，我們不會(huì)很隨意和混亂的去命名，有了依據(jù)，就能更輕松，也不易沖突。

　　詳細(xì)了解鏈接：https://smacss.com/

　　三、Meta CSS

　　原子類(lèi)，也可以稱(chēng)之為“無(wú)語(yǔ)義”類(lèi)，像這樣：

　　它的特點(diǎn)是什么？樣式和結(jié)構(gòu)、內(nèi)容無(wú)關(guān)，預(yù)先定義好這么一組規(guī)則，在需要的地方加上即可，我相信每個(gè)人第一次看到這種寫(xiě)法的時(shí)候，都會(huì)想：還能這樣寫(xiě)啊？！是的，總有一些人，一些新的思想和方法會(huì)涌現(xiàn)出來(lái)，它就是其中之一，當(dāng)然，并不是在稱(chēng)贊其本身有多么好，而是說(shuō)這種現(xiàn)象和過(guò)程是好的，它本身經(jīng)常被人吐槽，比如：“這樣寫(xiě)和直接內(nèi)聯(lián)有區(qū)別嗎？”、“如果要調(diào)整樣式，就要去改HTML，維護(hù)更加麻煩，也有違樣式和結(jié)構(gòu)分離的初衷”等等，其實(shí)我個(gè)人也是不贊成上面這種寫(xiě)法的，如果你要把這些抽離出來(lái)，那么還有什么抽不出來(lái)的呢？而且這些屬性，在項(xiàng)目之間，頁(yè)面之間，模塊之間，并沒(méi)有太大的通用性，把這些抽出來(lái)，只不過(guò)是稍微懶省勁兒些，但為了照顧到更多情況，你必須寫(xiě)入冗余代碼，是得不償失的。

　　雖然它有缺點(diǎn)，我個(gè)人贊成另外的一些東西分出來(lái)，比如：浮動(dòng)（float）、文本布局（text-align）、Flexbox布局等，這些是沒(méi)有那么多可能性的值，而且使用頻繁，復(fù)用方便，改動(dòng)較少，除此之外，你還可以提取另外一些公共的小顆粒類(lèi)，比如按鈕的種類(lèi)，文字顏色的種類(lèi)等，這些和CSS本身無(wú)關(guān)，和項(xiàng)目相關(guān)，這就是借鑒其思想，而不是直接拿來(lái)用。

　　四、BEM

　　嚴(yán)格說(shuō)來(lái)，BEM不是一套有骨有肉的模式，也不僅僅局限你在CSS的層面去規(guī)劃，它是一種怎樣去組織、編寫(xiě)代碼的思想，而且，看似簡(jiǎn)單的它，對(duì)前端界的影響卻是巨大的。

　　它的核心如下：

　　Block（塊）、Element（元素）、Modifier（修飾符）

　　它幫助我們定義頁(yè)面中每一部分的級(jí)別屬性，從某種意義上說(shuō)，也是一種“拆”。命名規(guī)則如下：

　　它的出現(xiàn)，曾給不少人帶來(lái)啟發(fā)，但是也有另一部分人仍然抱著挑剔的態(tài)度，譬如：

　　1、風(fēng)格不統(tǒng)一，顯得代碼不夠整潔美觀

　　2、可能會(huì)導(dǎo)致類(lèi)名過(guò)長(zhǎng)

　　還是前面說(shuō)的，你可以不去直接用它，但要清楚它的優(yōu)點(diǎn)：能夠使得我們僅通過(guò)類(lèi)名就知道哪些代碼是屬于一個(gè)模塊內(nèi)，以及在模塊中所起的作用。然后借鑒之。

　　當(dāng)然，BEM集聚了很多人的心血，也得到了很多的贊譽(yù)，其中就包括OOCSS的作者。所以，它肯定不是這么簡(jiǎn)單。它還會(huì)告訴你，怎樣配合著js來(lái)寫(xiě)，你的文件怎樣組織更好，項(xiàng)目該怎么構(gòu)建等。詳細(xì)可以到官網(wǎng)去查閱。地址：https://en.bem.info/

　　從實(shí)際出發(fā)，決定結(jié)果的人是你

　　到底怎樣使用設(shè)計(jì)模式？

　　雖然已經(jīng)有成熟的設(shè)計(jì)模式，但在實(shí)際當(dāng)中，你可能覺(jué)得哪個(gè)跟自己的項(xiàng)目都不能完全吻合，或者你要去為了使用它們而調(diào)整，成本很高。其實(shí)，我們不需要去迎合模式，要讓模式為我所用，你需要去了解它們背后的原理，要知道它們用什么方式解決了什么問(wèn)題，然后借鑒之，用它的方式解決我們的問(wèn)題，就好，這樣就不需要作難要不要用，也不需要糾結(jié)選哪個(gè)，不是簡(jiǎn)單的說(shuō)哪個(gè)好，哪個(gè)不好，總有我們能夠用得上它的地方。海納百川，集百家眾長(zhǎng)。

　　我個(gè)人一直以來(lái)所堅(jiān)持的另一個(gè)觀點(diǎn)就是，前端開(kāi)發(fā)的三駕馬車(chē)——html、css、js，不要，也不能孤立的去談那樣好或者這樣好，我們極少會(huì)有只用一次的代碼或者模塊，也不會(huì)只寫(xiě)一種語(yǔ)言，三駕馬車(chē)都是在一起協(xié)作的，都是會(huì)有復(fù)用、擴(kuò)展和團(tuán)隊(duì)合作多方面的因素在里面。故而，不能抱著這樣的想法：我現(xiàn)在就在做這個(gè)，它就是唯一的，就是固定的，沒(méi)問(wèn)題。其實(shí)很多問(wèn)題都是潛在的，要帶著發(fā)展眼光去看待。項(xiàng)目的文件之間，項(xiàng)目之間，團(tuán)隊(duì)成員之間，不論你的分工是哪塊，都要考慮到前后的影響和可能給合作帶來(lái)的不便。

　　怎樣才是最佳實(shí)踐？有“實(shí)踐”，才有“最佳”，脫離實(shí)際情況談最佳，就是空中樓閣。那么，最好的模式，不是哪個(gè)經(jīng)典的模式，而是在項(xiàng)目進(jìn)行中，不斷的磨合調(diào)整而出的。故而，不需要再懼怕看起來(lái)不明覺(jué)厲的設(shè)計(jì)模式，也不需要因?yàn)樽约哼€不懂設(shè)計(jì)模式而郁悶，它就是人們總結(jié)出來(lái)的實(shí)戰(zhàn)方法，你也可以有自己的模式~