CSS很容易，为什么大家还是把CSS

来源：众成翻译译者：liuliangsir

在你开始阅读这篇文章之前，(一定要做好心理准备)，因为我估计90％的前端工程师在看完之后心里都会很不爽。另外在文章最后，大约有10%的篇幅是用于介绍CSS技巧之最佳实践，所以我提前给你们打好预防针啦。

前端工程师在职业发展中可能会遇到以下困境：

某个阶段，感觉(自己所做的)工作没有任何难度
为团队创造的价值越来越低啦
自己做的事情，大家都能做

如果你确实也是这样，(恭喜你)，说明你也是他们当中的一份子。

而且说句实在话，CSS确实很简单。另外我可以保证，就算是傻子也能写出下面的代码：

所以，究竟是哪些事情给了你抱怨的勇气？堆纯CSS代码，是不需要任何技巧。而且在不用担心全局范围内的其它样式对元素样式覆盖的前提下，给该元素写样式也就变得很容易的观点是完全正确的。

所以从什么时候开始，写CSS就变得不那么简单？

后端开发工程师：“虽然我已经完成新功能的开发，但是我还是会通知前端，(内容大体上是这样子的)，我已经完成绝大部分开发，所以你前端只需要对细节进行微调，时间应该不会超过30分钟。”

于是我打开HTML文件，(吃惊地)发现到处都是弃用的HTML标签，而且丝毫没有考虑过响应式设计。深呼吸，(暗示自己)，他们写的CSS肯定会稍微好点。然而在我打开CSS文件之后，发现(同样)到处都是类似固定(fixed)定位、清除左浮动、右浮动以及!important的代码，于是我慢慢的把鼠标放进自己的衣领。

译者注：后端工程师写的CSS代码实在是辣眼睛，导致前端工程师没有办法继续阅读下去，所以才有把鼠标放进自己的衣领的动作。我比较纳闷的是，老外为什么是把鼠标放进衣领(neck有衣领的意思)，而不是放进口袋。

(安慰自己)，也许他们写出的代码不会一直这么糟糕下去。但是(在现实中)我很少遇到能够把前端代码写的这么6的后端工程师。很明显，写前端代码并不是后端工程师的职责所在。但是请后端工程师不要前端代码只写一半，然后希望前端工程师帮你擦屁股。

所以有什么东西可以有助于形成好的CSS？

(项目的)组织结构,尤其是当你做过大型项目，就会发现项目的组织结构真的很重要。关于项目组织结构写的比较好的技术文章，可以推荐你们去看Steven Bradley的目录结构可以帮你形成可维护的代码，这篇文章是为SCSS项目所写的，不过也可以将里面的工程经验应用到普通的CSS项目，另外本文的亮点在于教你如何将CSS项目的CSS文件拆分成便于维护的SCSS文件。

唯一性，这可能是我每天所遇到的最大问题。不幸的是，大部分工程师对CSS唯一性的理解存在误区，正是因为这样，才导致糟糕的CSS代码如!important烂大街。所以我们如何避免上述情况？这里有很多命名规范(旨在减少需要使用特定CSS选择器的场景)可以参考，假设你写的CSS没有上述问题，不过我还是建议你在非特殊情况下，应避免CSS类/元素选择器的深度超过3层。

恕我直言，命名规范，对于任何一个需要命名规范的大规模CSS项目来说是标配。没有命名规范，CSS项目将会变得难以维护。命名规范可以让我们很容易重用项目中的CSS以及在必要的情况下剔除项目中难以重用的CSS。我们仅列举几种比较流行的命名规范如：BEM，OOCSS，SMACSS以及我自己写的hiccup。

测试，是最容易让其他工程师忽略其它主观因素反而觉得后端工程师非常伟大的环节，因为你很容易在(后端工程师配置的)环境下进行开发。你知道作为前端工程师最痛苦的事情是什么吗？5+浏览器以及上千种移动设备，好的前端测试其实是个苦差，而且前端的测试大半都是很耗时的。我见过很多因为没有把前端测试考虑进去而导致项目延期的情况，而且前端测试实际花费的时间远比大多数人预期久。

所以你是如何纠正关于写CSS很简单的想法？

在以后工作中，再也不能让后端工程师们抱有侥幸心理。作为前端工程师，我们也没有将响应式的CSS代码只写一半，然后撒手不管，丢给后端工程师。所以为什么他们就能写无用的烂代码，然后在他们的CSS代码失效的情况下需要我们去打补丁？我不是责怪后端工程师来写CSS代码的这种做法，而是告诉他们，如果觉得写CSS很难的话，就不要去写。我只是不想让其他工程师也形成前端很简单的印象，如果不这样做的话，你需要通过努力工作来填后端工程师所埋的坑，而且不要让别人的意见左右你的想法。

本文由众成翻译（zcfy.cc）的译者翻译完成，抢先阅读更多优质英文技术文章，欢迎访问众成翻译。

五艺

既然写CSS很容易，为什么大家还是把CSS写的那么烂呢？