既然寫CSS很容易，那爲何你們仍是把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 很難的話，就不要寫。別讓其餘工程師以爲前端很簡單，前端纔不簡單呢，咱們前端工程師跟其餘人同樣努力地工做，別讓他們看走眼。

 

本文轉載自：衆成翻譯
譯者：liuliangsir
連接：http://www.zcfy.cc/article/1683
原文：https://hackernoon.com/if-css-is-so-easy-why-does-everyone-suck-e4442cc9428a#.bq9c1sev1

查看更多內容，請訪問個人博客 https://www.aaz5.com/index.php/archives/13/