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

本文由职坐标整理发布，更多相关内容，请关注职坐标WEB前端HTML/CSS频道！