既然写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 很难的话，就不要写。别让其他工程师觉得前端很简单，前端才不简单呢，我们前端工程师跟其他人一样努力地工作，别让他们看走眼。

小手一抖，资料全有。长按二维码关注京程一灯，阅读更多技术文章和业界动态。