CSS 很容易，那為什麼大家還是把 CSS 寫的那麼爛呢？

在你開始閱讀這篇文章之前，一定要做好心理準備。因為我寫的 90％ 都是在發牢騷，只有最後大概 10% 介紹 CSS 技巧之最佳實踐。提前給你們打好預防針啦。

前端工程師在職業發展中可能會遇到以下困境：

• 某個階段，感覺(自己所做的)工作沒有任何難度

• 為團隊創造的價值越來越低啦

• 自己做的事情，大家都能做

同意的請舉手。如果你確實是這樣，（恭喜你）說明你是多數派。

而且說句實在話，CSS 確實很簡單。另外我可以保證，就算是傻子也能寫出下面的程式碼：

p {
color: red;
}

那麼你還有什麼好抱怨的？堆純 CSS 程式碼，不需要任何技巧。而且只給單個元素新增全域性樣式，而不用考慮其他 CSS，當然是非常簡單的。

那麼CSS到底難在哪兒？

後端開發工程師：“雖然我已經完成新功能的開發，但是我弄亂了前端，不過你放心，我已經修好絕大部分，所以你前端只需要對細節進行微調，時間應該不會超過 30 分鐘”

於是我開啟HTML檔案，(吃驚地)發現到處都是棄用的HTML標籤，而且絲毫沒有考慮過響應式設計。深呼吸，(暗示自己)，他們寫的CSS肯定會稍微好點。然而在我開啟CSS檔案之後，發現(同樣)到處都是類似固定(fixed)定位、清除左浮動、右浮動以及!important的程式碼，於是我慢慢的把滑鼠繞在脖子上。（別攔我，讓我死）

（安慰自己），也許他們寫出的程式碼不會一直這麼糟糕，但是（在現實中）我幾乎沒見過後端工程師寫出能用的前端程式碼的。也還好啦，寫前端程式碼本來就不是後端工程師的職責所在。但是請後端工程師不要隨便寫一堆前端程式碼，然後指望前端工程師幫你擦屁股。

所以好的CSS長啥樣？

(專案的)組織結構。尤其是當你做過大型專案，就會發現專案的組織結構真的很重要。舉個正面例子——Steven Bradley 寫的 利於維護程式碼的目錄結構 ，這篇文章是為 SCSS 專案寫的，不過也適用於普通的 CSS 專案。它重點強調如何將 CSS 檔案模組化，形成便於維護的檔案。

規範。這可能是我每天所遇到的最大問題。不幸的是，大部分工程師對 CSS規範 的理解一知半解，正是因為這樣，才導致糟糕的 CSS 程式碼（如 !important）爛大街。那我們該如何避免呢？下面列出了很多值得參考的命名約定，它們旨在減少寫死的（非常依賴文件結構的） CSS 選擇器。假設你對此不感冒，我還是要勸你如無必要，避免使用超過 3 層的 CSS 類/元素選擇器。

命名約定。恕我直言，對於任何一個大型的 CSS 專案來說，命名約定是標配。沒有命名約定，CSS 就會變得既難維護又不可靠。命名約定可以讓我們輕鬆地重用專案中的 CSS，如有必要，還能幫我們剔除專案中多餘的 CSS。這裡僅列舉幾種比較流行的命名約定，如： BEM ， OOCSS ， SMACSS 以及我自己寫的 hiccup 。

測試。在這一點上，絕大多數其它工程師可能都沒發現當後端工程師有多爽。 因為後端工程師的開發工作只需要讓一個環境（網站所在的伺服器）正常即可。你知道作為前端工程師最痛苦的事情是什麼嗎？5 個以上的瀏覽器以及上千種移動裝置……好的前端測試工作其實是個苦差，且耗時很長。我見過很多專案延期，就因為沒有把前端測試考慮進去，而通常前端測試花費的時間會超出常人預期。

所以如何扭轉這種對CSS的天真看法？

在以後工作中，再也不能讓後端工程師們抱有僥倖心理。作為前端工程師，我們不會隨便把一堆無響應式的 CSS 程式碼丟給後端工程師，然後撒手不管。所以憑什麼他們就能寫無用的爛程式碼，然後在他們的 CSS 程式碼失效時讓我們去打補丁？我不是說要讓後端工程師好好寫 CSS 程式碼，而是我們應該告訴後端工程師，如果覺得寫 CSS 很難的話，就不要寫。

別讓其他工程師覺得前端很簡單，前端才不簡單呢，我們前端工程師跟其他人一樣努力地工作，別讓他們看走眼。