转载

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/ 。