用“五个为什么”写CSS_html/css_WEB-ITnose

相信大多数人都有过关于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的开发，用深入的根本原因连接不同元素甚至不同页面上出现的问题，这样使我们能够安心的以目前的问题等级来组织代码，等到再次碰到问题并找到这里，才再次重构以解决问题。

原文链接