既然写CSS很容易，那为何你们仍是把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 很难的话，就不要写。别让其余工程师以为前端很简单，前端才不简单呢，咱们前端工程师跟其余人同样努力地工做，别让他们看走眼。

 

本文转载自：众成翻译
译者：liuliangsir
连接：http://www.zcfy.cc/article/1683
原文：https://hackernoon.com/if-css-is-so-easy-why-does-everyone-suck-e4442cc9428a#.bq9c1sev1

查看更多内容，请访问个人博客 https://www.aaz5.com/index.php/archives/13/