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

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

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

到底为什么要审查CSS呢?

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

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

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

CSS如何工作

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

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

风格一致性

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

要提的问题

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

可用资源

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

浏览器兼容性

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

要提的问题

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

可用资源

权重

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

要提的问题

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

可用资源

预处理器的利用率

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

要提的问题

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

可用资源

性能

我把性能放在审查的最后不是不重视它,只是确保它是我们代码审查环节中最重要的一环。 高性能的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

如需转载,烦请注明出处:http://www.w3cplus.com/css/what-a-css-code-review-might-look-like.htmlAir Foamposite One Glowing

如需转载,烦请注明出处:https://www.w3cplus.com/css/what-a-css-code-review-might-look-like.html

如果文章中有不对之处,烦请各位大神拍正。如果你觉得这篇文章对你有所帮助,打个赏,让我有更大的动力去创作。(^_^)。看完了?还不过瘾?点击向作者提问!

赏杯咖啡,鼓励他创作更多优质内容!
返回顶部