【項目總結】扯一扯電商網站前端css的總體架構設計（1）

　　最近半忙不忙的寫了一個外包網站，網站主要功能是藝術品競拍和藝術衍生品的銷售。工程已經完成了80%左右，如今先後端代碼量已經50W行左右，我主要負責的是前端設計和前端佈局。下面就先放一個網站的設計圖吧，由於涉及到甲方的「商業機密」，因此打一下馬賽克：

　　

　　

　　這篇文章主要算是我對於這個項目的總結或者說是對於這階段本身看的一些前端書或者經驗的一個總結吧，因此設計圖就不貼那麼多了。整個項目的設計圖由最開始的ui定了個首頁稿基調，剩下的界面大部分都是我在首頁稿基礎上作出來的，之後有機會再嘮。PS:不過話說博客園裏如今遍園子都是.net的文章，前端的文章除了js的，就是那些「可複製可粘貼」的源碼文，但願之後能看到更多前端好文吧。

　　整個網站的單界面（不包括後端）已經有3,40個了，css文件累積下來也有10多個（這個以後會細說，這塊兒是我這個項目中作的最失敗的一部分，也是我寫這個blog的緣由）。

　　

　　

　　一個一個問題的嘮,我就說說本身的理解，不太對的地方歡迎交流：

　　1、什麼是css的架構？爲何要作架構？

　　　　若是作的是一個小的博客網站或者說是一個小的CMS，那可能不少時候不用考慮css的架構，由於css文件不多，總共就不到10個界面，給每一個界面單獨寫樣式、單獨封一個css文件也沒有太大的工程量。可是，若是換到這種界面數達到幾十個或者幾百個的大型網站中，css的架構就很是有必要了。並且，好的架構可以幫助團隊共同開發，不可能說總共幾十個界面，3個前端，一人分十幾個，好，大家去寫吧，這樣的工做效率過低，並且極易致使樣式衝突和樣式被覆蓋，可能寫起來很快，每一個人都很勤勞的把本身的代碼寫完了，而後後端總合以後發現樣式全亂了，一改改了好幾天，比寫都慢。

　　　　合適的css結構可以幫助開發者減小代碼量，可以幫助前端開發團隊在共同開發的過程當中可以更好的合做。同時它也能優化前端的總體結構，合理的css架構可以減小css文件數目和css文件總大小，下降對服務器的訪問壓力。

　　　　它也能大幅度提升前端代碼的重用度和減小代碼的維護成本。對於那種1個小時想改一次界面的甲方，沒有好的css架構真是要瘋了。好比說你每一個頁面都有個標題欄，每一個頁面都是一個單獨的css，而後忽然有一天甲方深井冰同樣說，我想改一下樣式，這時候你只有兩個辦法：1.抱着甲方大腿哭訴求不改2.默默打開電腦開始一個界面一個界面的改。看到這裏不少有開發經驗的同志們應該都知道說，提取這個標題版塊，寫在統一的css文件內，每一個界面都引用一下，最後想改的話只要去總的那個css文件裏面改就能夠了。這就是最簡單的模塊化，不過，模塊化的過程當中還有不少問題須要注意：1.好比3個界面都有標題欄，可是3個界面對於標題欄字體顏色的要求各不相同怎麼辦？對於上下margin的要求又不相同怎麼辦？2.忽然多了一個界面，它有標題欄，可是它標題欄裏多了個背景圖片，這個怎麼解決？再麻煩一點，它標題欄裏多了一個<p>表籤，多出來的又怎麼佈局？這種解決模塊之間差別的問題確實值得好好研究一下。

　　　　一般的css架構，或者是當前網站的css框架，包括了對瀏覽器默認樣式的覆蓋重置、對網站內部模塊的提取抽象化、約定css代碼規範、衝突解決等功能。若是項目中有引用其餘的成熟框架，好比說bootstrap、yui,怎麼把這些框架和本身寫的分割開，能實現樣式而又不衝突？稍後慢慢嘮。

　　　　怎麼作css架構或者怎麼實現簡單的css結構？

　　　　答：寫代碼啊！

　　

　　2、css的架構從哪裏作起呢？

　　　　動手一個項目前，不能看到設計圖就直接幹，應該先想的是怎麼樣去寫。就像咱們老師最常對咱們說的同樣「只會寫代碼，你只是平庸的程序員。可以作出好的架構或者可以安排好項目怎麼開發的，纔是高端點兒的程序員。平庸的程序員只能吃香蕉，高端的程序員有時候還能吃點菠蘿、蘋果啥的」。直接動手開始寫，寫着寫着就會發現不少時候本身是在作重複功，不斷地複製粘貼或者是爲了一個界面模塊重寫一種又一種樣式，或者寫着寫着發現「臥槽，衝突了，樣式亂了」，再或者寫着寫着發現本身寫的不對想回去改，而後開始挨個文件的改...這種沒有架構的、笨拙的在寫css就是在幹體力活，好久以前寫的一個項目就是這樣，20幾個界面慢慢改去吧，改了整整兩天，都要瘋了...

　　　　動手一個項目前，最起碼的，應該想清楚大體有多少個css文件，哪些css文件須要先寫出來一個固定版本，哪些css代碼可能會大量重用，哪些css文件可能會有大規模的改動。而後根據這些css的詳細要求去開始動手寫第一版。

　　　　好比我上面放的截圖，最直觀的header首部欄：，在每一個界面都是同樣的。固然這個咱們能夠在後端裏面用分佈視圖layout來實現，可是在界面前端實現的初期，是否是也應該把這一起的html、css、js抽離出來，這樣在後端進行最後整合的時候也能快一些，並且萬一碰到個聖誕節，客戶說給上面背景色換成藍色吧，這樣直接翻到header.css裏改一改樣式就行了，不用苦逼的去「體力活」了。

　　　　因此，第一種css前端架構設計的方式就是：按照區域劃分。

　　　　按照頁面內的元素或者模塊的區域定位，網站中能夠劃分出來不少區域：header、footer、sidebar、slogan等等，針對於這些區域單獨定位可以有效的實現分佈視圖的劃分，每一個區域都被抽離出來，新建一個界面的時候咱們只須要在裏面拼一拼就行了。沒記錯的話，yui就是這麼幹的。

　　　　在這個拍賣網站的css裏我沒有單獨抽離出來，由於我以爲單獨抽離成一個header.css、footer.css文件有點贅餘，css文件數在增多，而每一個文件內的代碼行數卻不多。這個還要根據具體代碼來看，一個footer樣式寫了幾十行的話，那就抽離成一個文件吧。因此我在總的css文件:layout.css裏實際上是按照區域進行寫的：。當我想要更改底部導航樣式的時候，直接就去layout.css裏往下翻找，改掉就能夠了。

　　　　

　　　　然而咱們對界面進行分割以後發現，仍是有不少代碼在大量重複出現，好比說登錄框、好比說表格、好比說文本框等等，因此有了第二種劃分方式：按照功能進行劃分。

　　　　按照功能劃分就是看元素的界面內功能是什麼，而後根據具體功能，把具備相同功能的元素、模塊抽離出來：font、color、button、form等等，這個應該是如今不少成熟框架採用的模式，好比我大bootstrap就是這麼幹的，下面是bootstrap2.3的less文件夾的截圖，很明顯，都是一個個功能模塊，最後咱們直接應用的是被所有整合壓縮的.min.css，裏面其實也仍是這種結構：

　　　　

　　　　按照功能劃分仍是蠻爽的，由於你能夠爲每一個功能劃分添加統一的前綴，在有代碼提示的編譯器裏寫代碼簡直極速。換成那種按區域劃分的話，有時候就略微蛋疼了「哎呀，頁腳的css名是什麼？哎呀，小王寫的那塊兒側邊欄的類名是什麼」。

　　　　在這個項目的代碼裏，我其實採用的是第一種方式和第二種方式混用的模式，從我上一張css文件截圖就能看出來，我不只把重複出現的區域模塊的代碼抽象了出來，並且也把側邊欄、遮罩這種功能模塊給抽象整理了出來，儘可能提升個人代碼的複用度。

　　　　以前還以爲本身的這個項目的架構作的不錯，可是後來越寫越坑，由於不少時候本身都是在作無用功。我犯的傻X錯誤：

　　　　　　1.模塊抽象有侷限。好比說表單有要差一個特殊的元素，原來寫好的模塊就無法用了，又得重頭寫一遍。

　　　　　　2.模塊抽象不徹底。在我認爲本身已經把模塊抽象作的差很少的時候就開始全力寫，寫着寫着發現，有的模塊被遺忘了，不少模塊須要一遍一遍的手寫。

　　　　　　3.css類名不規範說究竟是模塊沒有劃分好。這個網站寫到如今，個人命名已經詞窮了，它這裏有不少界面：加入購物車、加入收藏列表、查看購物車、確認支付、填寫確認訂單、一口價支付...沒有好的英文底子真是噩夢...因此只能翻譯漢語名，而後駝峯命名法：AddCart。其實命名法還有不少，駝峯命名法最大的好處就是能夠很直觀的命名，不用考慮別的，可是駝峯命名法在子類命名的時候就比較頭疼了，一個又一個的長單詞...另外一種命名方法是劃線法，爲了不麻煩直接用的下劃線沒用中槓add_cart，這種命名法對於子類命名特別爽，這個後幾篇總結的時候再嘮。

　　　　------------下面---------就是------------本篇-------核心-----了---

　　　　下面就是本篇文章的【核心】了，也是我痛心疾首的反思T^T最近項目受阻、半寫不寫的狀態，因此看了一些前端代碼規範、網站前端開發的總結的書，而後發現了一種新的結構方法，看完以後真是整我的都很差了。推薦這本書《編寫高質量代碼-web前端開發修煉之道》

　　　　另外一種比較推薦的css架構方法是：按照界面職能進行劃分：這裏將網站的整個前端抽象成了一個軟件或者是一個項目，這時候咱們要考慮的就是項目底層是什麼，項目的表現層是什麼，相似於你們常說的mvc的思想，把前端架構也進行mvc般的劃分，能夠把全部的css文件概括爲三類：

　　　　　　1.base類 　　2.common類　　3.page類

　　　　這三類並非像區域架構、功能架構中並列做用的模式，而是以base類爲底層，逐層影響，層疊做用，大概畫了個做用圖：

　　　　確實，就像這種金字塔結構，下面詳細介紹一下每一個類的做用。

　　

　　　　[1.base類]

　　　　　　顧名思義，基礎，它是整個css架構中最基礎的部分。它負責提供瀏覽器默認樣式重置、基礎功能實現。說到base裏的基礎功能實現，它主要指的是那種涉及範圍極小、抽象程度高的原子級別的功能類實現。好比咱們最多見的.f12{font-size:12px;}，.mt30{margin-top:30px;}，每個原子類只負責實現一種功能，絕對不涉及到具體的頁面ui，只是爲上幾層提供原子功能，具體某模塊的實現則有這些原子類間進行組合實現。固然，base類還要負責瀏覽器默認樣式的reset，這個我以爲yui實現的就很靠譜，如今不少網站的<h123456>都是不加粗的，這個都須要提早在reset部分寫好。

　　　　　　base類是整個css架構的地基，全部界面都會引用整個文件，這對這個文件提出了要求：1.文件大小不能過大 2.文件可靠性要高，不能出現多個版本 3.寫成以後儘可能減小維護次數或者儘可能不用維護。並且不一樣網站的base類能夠共用，由於base類不涉及任何具體的ui樣式，高度可移植。

　　　　　　具體base類文件都有什麼，這個下一講來好好嘮嘮，今天沒空了。

　　　　[2.common類]

　　　　　　普通類，它是利用css基礎類實現的基礎模塊的css文件，咱們已經把整個界面裏的文字、邊距、顏色等原子工程抽離出來了，如今須要咱們爲當前網站定製模塊了。

　　　　　　設計原則裏「統一性原則」要求到同一網站必須保持風格一致，你不可能首頁扁平化，進了列表頁就來個高光高陰影還帶酷炫flash的web2.0風格頁。因此，同一網站內的搜索框、文本框、按鈕、列表大多數狀況下都是統一風格的，因此這就給咱們個機會，把這些會重複出現的模塊抽離到common類裏，相似於MVC裏面的model，也相似於咱們上面講述的架構功能劃分的具體功能文件。爲了儘可能保證可重用和靈活使用，咱們須要對這些模塊進行完整封裝。

　　　　　　話說，模塊須要進行訂製時怎麼辦？

　　　　　　我想到了兩個辦法，一種是利用less等語言給模塊預留樣式接口，直接修改配置文件，再動態輸出css文件。2.儘可能減小模塊的ui屬性，好比bgcolor或者是border，能夠空缺，而在實際使用時根據本身的須要與原子類進行組合。可是這種方法可能會對原子類有要求並且會對base文件產生影響，因此我本身又編出了個詞：分子類，顯而易見就是提供針對於模塊的大原子類定製，爲每個模塊定製專屬樣式類，一樣至於common層，須要定製模塊樣式時只須要彼此組合便可。以後的文章裏寫點東西示範一下。　　

　　　　[3.page類]

　　　　　　頁面類，從圖裏也能看出來，它在金字塔的塔尖，而它的做用範圍也是最小的，就是每個頁面，到不至於每個頁面一個css，可是也差很少吧。 page類就是負責提供頁面級樣式的。page類css可能產生一些比較使人糾結的問題：1.page太多，因此page css單文件太多，每個文件就是一個http請求，服務器能受得了不？2.page css爲了避免多，因此合併在一個page.css裏，可是命名怎麼辦？好比.part, .one, .main, .theme....這些頻繁出現的類名合併衝突怎麼辦？

　　　　　　第二個問題能夠經過命名範圍限定來解決。

　　　　　　至於第一個問題，你能夠把css單文件合併，而後你就去看第二個問題的答案吧。

　　　　　　

　　　　　　總結下來，在開發中，base和common類通常由一我的完成，在他完成這些類以後其餘人接手項目，開始添些page.css，因此page層裏代碼奇多，若是應用到分佈視圖，一個整頁面實際上是由若干個小界面拼起來的，那麼如何避免衝突？如何避免樣式覆蓋？之後詳談。

 

　　　　

　　　　　_(:з」∠)_碼了這麼多字累死我了，今天就先寫到這。下篇見~~【求交流求師傅帶求內推求不吐槽...】

　　　　　下一篇文章，我們詳細談談base類css文件，以及我本身對項目css的重構。　　

　　　　　最後，最後，我想說的就是↓↓↓