既然写 CSS 很容易,那为什么大家还是把 CSS 写的那么烂呢?
在你开始阅读这篇文章之前,一定要做好心理准备。因为我写的 90% 都是在发牢骚,只有最后大概 10% 介绍 CSS 技巧之最佳实践。提前给你们打好预防针啦。

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

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

同意的请举手。如果你确实是这样,(恭喜你)说明你是多数派。

为什么前端工程师讨厌后端工程师动她的代码?——CSS恩怨情仇0

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

p {

color: red;

}

所以你还有什么好抱怨的?堆纯 CSS 代码,不需要任何技巧。而且只给单个元素添加全局样式,而不用考虑其他 CSS,当然是非常简单的。
那么CSS到底难在哪儿?
为什么前端工程师讨厌后端工程师动她的代码?——CSS恩怨情仇1

后端开发工程师:“虽然我已经完成新功能的开发,但是我弄乱了前端,不过你放心,我已经修好绝大部分,所以你前端只需要对细节进行微调,时间应该不会超过 30 分钟。”

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

(安慰自己),也许他们写出的代码不会一直这么糟糕,但是(在现实中)我几乎没见过后端工程师写出能用的前端代码的。也还好啦,写前端代码本来就不是后端工程师的职责所在。但是请后端工程师不要随便写一堆前端代码,然后指望前端工程师帮你擦屁股。
所以好的 CSS 长啥样?
为什么前端工程师讨厌后端工程师动她的代码?——CSS恩怨情仇2

项目的)组织结构。 尤其是当你做过大型项目,就会发现项目的组织结构真的很重要。举个正面例子——Steven Bradley 写的“利于维护代码的目录结构”。这篇文章是为 SCSS 项目写的,不过也适用于普通的 CSS 项目。它重点强调如何将 CSS 文件模块化,形成便于维护的文件。

规范。这可能是我每天所遇到的最大问题。不幸的是,大部分工程师对 CSS 规范的理解一知半解,正是因为这样,才导致糟糕的 CSS 代码(如 !important)烂大街。那我们该如何避免呢?下面列出了很多值得参考的命名约定,它们旨在减少写死的(非常依赖文档结构的) CSS 选择器。假设你对此不感冒,我还是要劝你如无必要,避免使用超过 3 层的 CSS 类/元素选择器。

命名约定。 恕我直言,对于任何一个大型的 CSS 项目来说,命名约定是标配。没有命名约定,CSS 就会变得既难维护又不可靠。命名约定可以让我们轻松地重用项目中的 CSS,如有必要,还能帮我们剔除项目中多余的 CSS。这里仅列举几种比较流行的命名约定,如:BEM,OOCSS,SMACSS 以及我自己写的 hiccup。

测试。 在这一点上,绝大多数其它工程师可能都没发现当后端工程师有多爽。 因为后端工程师的开发工作只需要让一个环境(网站所在的服务器)正常即可。你知道作为前端工程师最痛苦的事情是什么吗?5 个以上的浏览器以及上千种移动设备……好的前端测试工作其实是个苦差,且耗时很长。我见过很多项目延期,就因为没有把前端测试考虑进去,而通常前端测试花 费的时间会超出常人预期。
所以如何扭转这种对CSS的天真看法?
为什么前端工程师讨厌后端工程师动她的代码?——CSS恩怨情仇3

在 以后工作中,再也不能让后端工程师们抱有侥幸心理。作为前端工程师,我们不会随便把一堆无响应式的 CSS 代码丢给后端工程师,然后撒手不管。所以凭什么他们就能写无用的烂代码,然后在他们的 CSS 代码失效时让我们去打补丁?我不是说要让后端工程师好好写 CSS 代码,而是我们应该告诉后端工程师,如果觉得写 CSS 很难的话,就不要写。别让其他工程师觉得前端很简单,前端才不简单呢,我们前端工程师跟其他人一样努力地工作,别让他们看走眼。

本文由众成翻译(zcfy.cc)的译者翻译完成

余下全文(1/3)
分享这篇文章:

请关注我们:

发表评论

邮箱地址不会被公开。 必填项已用*标注