相信大多數人都有過關於CSS的痛苦經歷，從我加入公司到現在，不到兩年的時間裡，聽到最多CSS相關的討論就是‘很難調’。所以我也一直在探究這其中有怎樣的問題，為什麼很多人覺得CSS很難寫，如何才能讓其他人更優雅的寫CSS。在Code Review的時候，我漸漸的發現了問題所在，其實很多人已經掌握了豐富的CSS知識，但卻不知道如何分組屬性寫成class。最後只好在需要改變樣式的元素上隨意起個名字做class然後把所有要寫的屬性丟進這個class裡，如果優先級不夠，再把前面的選擇器都加上。結果就是CSS代碼不斷堆積，重復和冗余不斷增多，維護也變得舉步維艱。
問題找到了，但如何解決呢，雖然我在項目組內做了幾次分享，還經常在Code Review的時候提出一些問題，卻還是收效甚微。有時候知道什麼是正確的很容易，但知道如何才能做到正確卻很難。直到最近，看了幾本書之後，發現了一個很適合指導設計CSS的方法，那就是五個為什麼或者叫五問法。五問法來自豐田的精益生產，後來自然衍生到了精益創業中，在DDD以及UX相關書籍中都會見到這個方法，其主旨是深入發覺大量現象的背後所隱藏的真正原因。乍一看它是一個管理方法，其實我覺得它是一種思維方式，即刨根問底的找到問題的根本原因並解決。所以被應用於各個領域，自然對於CSS所面臨的問題也正恰如其分。
場景示例
先來舉個例子吧，某天Code Review發現了一條CSS代碼是這樣寫的：
CSS Code復制內容到剪貼板
.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的開發，用深入的根本原因連接不同元素甚至不同頁面上出現的問題，這樣使我們能夠安心的以目前的問題等級來組織代碼，等到再次碰到問題並找到這裡，才再次重構以解決問題。