转载

CSS代码审查可能会是什么样子

许多编程语言在部署之前会有代码审查。 无论是快速过一遍,或者深度审查,又或者是完整的单元测试,代码审查都会让我们在发布代码时更有自信。

我开始琢磨CSS代码审查会是什么样子。 CSS有很多种书写方式,“最好的方式”通常是因项目而论。 我这样说,绝对不是要写一篇教条的文章,而是为讲CSS发布之前从何处着手审查做铺垫。

到底为什么要审查CSS呢?

首先我们可以怀疑为什么想要审查CSS,审查也会耗费时间、成本、精力和其他东西,看起来会阻碍我们交付产品。

然而,做代码审查,我们退后一步,卸掉我们的战斗装备,给我们的工作一个诚实的评价,或者让另外一个人从新的视角来看。这样是把我们和机器分离开,最终,会帮助我们在代码发布之前提前解决一些让人头痛的bug和性能问题。

除了可以将bug掐死在摇篮里,还有很多其他的好处。我发现,根据这些好处把代码审查分成几个具体的方面,会帮助梳理架构这个话题,并且能优先讲述认可的方面。对你而言的好处可能和我这里将要说到的不太一样,但是这里提到的都是我遇到过多次的。

CSS如何工作

我们有必要简单地看一下CSS是做什么的。它的首要任务是给页面预期的风格。与设计模型匹配啦,适合样式标准啦,或者其他应该做的东东。并且要满足可变的内容(不同长度标题和内容,不同尺寸的图片,等等),如果不,那就需要先解决这个问题。

如果是响应式设计,要确保设计在每个断点处流畅地做了该做的事。

风格一致性

这里是要保证CSS写得好,有条理的,有文档。从其他开发者那里接手过项目的人很清楚这样做的好处。代码使用一致的命名约定并且有全面的文档比较容易快速接手,并且为将来维护代码提供指导。

要提的问题

  • 这个项目有可用的CSS样式指南吗?如果有,代码是根据指南来写的吗?
  • 有全面的开发文档吗?有混乱的元素,属性或者其他开发者不知道为什么这样写的技巧吗?
  • 在元素命名和组织属性方面有明显不一致吗?

可用资源

  • CSS Lint : 一个发现错误或矛盾的优秀工具。它甚至可用于 Grunt 和 Gulp 任务当中。
  • CSS Style Guides : 一个样式指南文档,你可以用根据这份文档制作出适合你或团队的样式指南文档。
  • What makes for good docs? : Dave DeSandro的整理的如何编写好的文档。

浏览器兼容性

一旦CSS有组织并且具有一致性,我开始把注意力放在它在不同浏览器和不同设备上的表现。代码写的漂亮是一回事,但如果它在该生效的时候表现不好,就没有什么意义了。

要提的问题

  • 项目要支持哪些浏览器和设备?我们可以用它们来测试吗?
  • 有对这个网站做分析吗?如果有,有告诉我们哪个浏览器要重点测试吗?
  • 有针对特定浏览器或设备的hack吗?如果有,涉及到其他的方法吗?这些都有良好的文档吗?

可用资源

  • Can I Use : 一个索引了CSS属性兼容哪些浏览器及哪些版本的中央存储库。
  • Ghostlab : 一个跨多个设备同步浏览器测试的应用程序。
  • Opendevicelab.com/ : 一个交互式地图,找到附近的测试设备实验室。
  • Establishing an Open Device Lab : Smashing Magazine 深入研究了设备实验室的好处,并且指导如何创建它。
  • Support vs. Optimization :Brad Frost 很好的覆盖了两者之间的不同以及如何影响编码的方式。
  • 跨浏览器测试服务: Cross Browser Testing 或 Browserstack .

权重

现在是时候衡量代码中的特定元素是什么并且判断是否可以重构。这将创建负责任的级联样式,代码是模块化或者特定化,正如我们想要它们成为的样子。

要提的问题

  • 有什么地方用了ID吗?如果有,可以用class代替吗?关于这个样式指南里是怎么说的?
  • 代码里有 !important 吗?如果有,为什么要用它,可以避免使用它吗?
  • 我们依赖前缀吗?如果是,有没有为不支持的浏览器组织合适的默认的前缀?
  • 代码是如果模块化的?它们通过“Kitchen Sink”测试吗? 它们都用在相同的HTML文档中吗?

可用资源

  • CSS Specificity Graph Generator : 可视化样式表中权重的工具。
  • Specificity Calculator : 可视化元素权重的一个很好的方式
  • Specifics on CSS Specificity : 讲什么是权重和它的样式级联效应。
  • Responsive Deliverables : 我喜欢“Mini Bootstrap” 的想法,它对于测试权重也是很棒的。

预处理器的利用率

如果项目没有用到预处理器,可以忽略这个。但如果用到了,一定有很多额外的事情要考虑。

要提的问题

  • 现有变量用在了它应该用在的地方吗?新的变量有被解释吗?如果有,它是有意义并且有文档的吗?
  • 其他的抽象体(比如扩展、混合、循环、map等等)被有效利用了吗?
  • 新的CSS放在恰当的局部模块了吗?新的局部模块被用到了吗?架构方面它们有意义吗?
  • 它们有参照已经有的预处理器特定的样式指南吗?

可用资源

  • CSS-Tricks上的 Sass样式指南
  • Hugo Giraudel的 Sass指南

性能

我把性能放在审查的最后不是不重视它,只是确保它是我们代码审查环节中最重要的一环。 高性能的CSS往往与代码精简度以及它是如何打包、服务有关,因此把性能放在代码审查的最后是合理的——虽然我们在写代码的时候就一直在考虑性能。

要提的问题

  • 最终CSS文件有多大?我们打算压缩使它变小吗?(是的,请这样做!)压缩之后文件大小有什么变化?
  • 我们加载了多少样式表(通过 <link>@import 方式)?我们可以减少加载数量吗?可以有条件的加载吗?异步加载?
  • 线上缓存CSS吗?

可用资源

  • CSS Stats : 输入一个网站的URL,可以返回大量的统计数据,包括用到的所有字体和颜色的报告。
  • CSS Dig : 跟CSS Stas非常相似,但是包装成了一个很方便的谷歌浏览器扩展件。
  • unCSS : 可以与HTML和JavaScript标记比对,移除没有用到的CSS。可以用于Grunt、 Gulp和Broccoli。
  • Critical CSS : 可以根据给定页面的HTML标记创建单独的CSS文件,这个优化和 Google PageSpeed Insights 的建议是一致的。
  • loadCSS : 一个异步加载CSS的函数。

总结

这里提到的每一个问题和工具,不是所有的项目都需要或相关。实际上,可能有更多的问题和工具要考虑或用到。在你发布CSS之前有经常要考虑到的问题吗?比如比较适合你的项目的?欢迎和我们一起分享!

另外,审查我们代码的目的不是要强求完美。我们在CSS中会因为很多原因(无论是有意为之或其他)做出妥协。回顾一天的工作,我们有努力做好每件事就已足够^_^。

本文根据 @Geoff Graham 的《 What a CSS Code Review Might Look Like 》所译,整个译文带有我们自己的理解与思想,如果译得不好或有不对之处还请同行朋友指点。如需转载此译文,需注明英文出处: https://css-tricks.com/what-a-css-code-review-might-look-like/ 。

风儿筝

小前端一枚,生活在北方美丽的海滨城市。喜欢这个职业,hard working & learning。 喜欢听歌,跑步,烹饪, and more。新浪微博:@风儿筝2014

正文到此结束
Loading...