用「五個爲何」寫CSS

相信大多數人都有過關於CSS的痛苦經歷，從我加入公司到如今，不到兩年的時間裏，聽到最多CSS相關的討論就是‘很難調’。因此我也一直在探究這其中有怎樣的問題，爲何不少人以爲CSS很難寫，如何才能讓其餘人更優雅的寫CSS。在Code Review的時候，我漸漸的發現了問題所在，其實不少人已經掌握了豐富的CSS知識，但殊不知道如何分組屬性寫成class。最後只好在須要改變樣式的元素上隨意起個名字作class而後把全部要寫的屬性丟進這個class裏，若是優先級不夠，再把前面的選擇器都加上。結果就是CSS代碼不斷堆積，重複和冗餘不斷增多，維護也變得舉步維艱。

問題找到了，但如何解決呢，雖然我在項目組內作了幾回分享，還常常在Code Review的時候提出一些問題，卻仍是收效甚微。有時候知道什麼是正確的很容易，但知道如何才能作到正確卻很難。直到最近，看了幾本書以後，發現了一個很適合指導設計CSS的方法，那就是五個爲何或者叫五問法。五問法來自豐田的精益生產，後來天然衍生到了精益創業中，在DDD以及UX相關書籍中都會見到這個方法，其主旨是深刻發覺大量現象的背後所隱藏的真正緣由。乍一看它是一個管理方法，其實我以爲它是一種思惟方式，即刨根問底的找到問題的根本緣由並解決。因此被應用於各個領域，天然對於CSS所面臨的問題也正恰如其分。

場景示例

先來舉個例子吧，某天Code Review發現了一條CSS代碼是這樣寫的：

.max-width {
    max-width: 300px;
}

由此產生了如下對話（純屬虛構）：

UI Dev：「不該該這樣寫，這和直接寫內聯樣式有什麼區別呢？」

Dev：「若是我不加最大寬度，頁面上那個元素左邊就會多出一部分，否則加個margin外邊距能夠嗎？」

UI Dev：「這個...我也不肯定，我從沒遇到過這樣的問題，必定是哪裏有問題。」

Dev：「確實這樣寫也挺很差的，過一段時間就不知道這行代碼什麼意思了，也不敢修改它。但究竟應該如何寫呢？」

UI Dev：「呃，這樣吧，咱們來試試五個爲何，找找問題的根本緣由。」

Dev：「好啊，CSS的問題也困擾我很久了，能解決就最好了。」

UI Dev：「首先問問，爲何要給元素加最大寬度呢？」

Dev：「由於不加就就會多出一部分呀。」

UI Dev：「那爲何這個元素會多一部分呢？」

Dev：「由於沒加最大寬度，開個玩笑，別生氣，其實我也不肯定，不過用DevTools看了一下，好像它的父元素的寬度也不對。」

UI Dev：「已經接近了，爲何父元素的寬度不對？」

Dev：「由於父元素的內邊距兩邊不同。」

UI Dev：「爲何父元素的內邊距不一致？」

Dev：「啊，我知道了，原來爲父元素的父元素寫了一個last的僞選擇器，它是用來把padding-right設爲0的，由於父元素如今正好是最後一個，因此被影響了。」

UI Dev：「別急，爲何要把最後一個元素的padding-right設爲0？」

Dev：「由於原先最後面的那個元素裏面是一個沒法修改樣式的控件，須要把padding-right設爲0才能放得下。」

UI Dev：「因此這纔是問題所在，咱們的意圖是給空間的容器加上padding-right爲0的屬性對嗎？而不是給最後一個元素加，因此應該寫一個class，也許叫作‘widget-container’之類的，放在那個容器上，而後把last僞選擇器刪掉，如此一切就正常了。原先出問題的地方實際上是沒問題的。」

Dev：「原來是這樣，太好了，我學到了，樣式出問題的地方不必定是代碼有問題的地方，五個爲何太有用了。」

這樣反覆問屢次「爲何」可讓咱們找到問題的根本所在，若是僅僅從表面現象去解決問題極可能致使南轅北轍的後果。並且在例子中的last僞選擇器就是由於沒有找到根本緣由而簡單粗暴的寫了這樣一行代碼而致使的。這個例子還很好的展示了五個爲何對於CSS的益處，不只是找到問題的根本緣由，還使得咱們在寫CSS的時候意圖更加明確。如此一來，class命名難的問題也迎刃而解，padding-right應該爲的0的元素是那個控件的容器，因此很容易想出「widget-container」這樣的名字，由於經過五個爲何的方法找到了真正的意圖，此時，class叫什麼和應該放在哪都是水到渠成了。

按比例投入

但有時候咱們所面對的項目不會這麼善良，「爲何」的層級越多，說明CSS的關係也越複雜，因此如今咱們來談談五個爲何中的一個重要原則，按比例投入。其主旨是小問題小投入，大問題大投入，問題等級越高，投入也應該越大。在CSS中來說，就是當發現樣式異常時，使用五個爲何深刻找到的根本緣由所在之處的重複次數越多，說明問題越嚴重，對問題的解決方案也應投入的更多。

再回到上面的例子中，經過一個元素位置異常的問題，找到根本緣由來自一個控件須要內邊距爲0的容器元素，因爲第一次發現，因此選擇投入較小的解決方案，針對該控件加一個class用來去掉內邊距。目前看來是很正確的，但若是連續不斷的從不一樣的問題上深刻找到這個控件上，那就說明問題等級提高了，不該該僅僅是在每一個調用控件的容器上添加該class。此時咱們能夠考慮其餘方式，好比把全部容器內邊距都設爲0，而有針對性的對內部元素添加外邊距，若是問題等級繼續提高，還能夠修改甚至替換控件，或者重構其餘部分來適應該控件。總之就是要按問題等級選擇解決問題的手段，這樣的好處不只僅是原先在精益中那樣能夠自動調節效率，還能夠等樣式需求更明確的時候做出相應的重構。

因爲CSS的描述性，使得它很自由，因此同一個需求，每每一百個開發者有一百種實現。在第一次碰到一個需求時，更是很難寫出最佳實現，只能有針對性的寫一個專屬class把須要的屬性扔進去。其實問題不在於此，而在於以後是否能在相同問題出現時重構原先的代碼，根據全部相關問題寫出更具普適性的class。有經驗的UI Dev有時會經過經驗來判斷，直接寫出這種class，Bootstrap這類框架就是這樣的，但沒有或較少經驗的開發者就會產生疑惑。五個爲何的按比例投入原則能夠很好的驅動CSS的開發，用深刻的根本緣由鏈接不一樣元素甚至不一樣頁面上出現的問題，這樣使咱們可以安心的以目前的問題等級來組織代碼，等到再次碰到問題並找到這裏，纔再次重構以解決問題。

原文連接