快速 CSS 审计及关于设计系统的说明

我最近一直在审计大量的 CSS 代码，并且认为记下我的审计方法会很有趣。我确定根据您的应用程序的规模和您的 CSS 在幕后工作方式，有无数种不同的方法可以做到这一点，因此请您对所有这些内容保持谨慎。

首先声明几点：在我现在工作的公司 Gusto，我们的工程师和设计师都在使用 Sass 并使用 webpack 将这些文件编译成 CSS。我们的生产环境将所有这些代码最小化到一个 CSS 文件中。但是，我们的 CSS 由三个独立的域组成，因此我将它们都下载到我的桌面上，因为我想单独测试它们。

以下是这些文件的用途

• manifest.css：一个从我们所有 Sass 函数、mixin 生成的文件，并包含我们所有默认的 HTML 样式和实用程序类。
• components.css：一个由我们的 React 组件组成的文件，例如 Button.scss、Card.scss 等。它和 manifest.css 都来自我们的组件库代码库，并被导入到我们的主应用程序中。
• app.css：一个覆盖我们的组件和 manifest 的样式集合。目前，它存在于我们的主应用程序代码库中。

下载完所有内容后，我将它们扔到一个 S3 存储桶中，然后通过 CSS Stats 运行它们。（我找不到一个我喜欢的命令行工具，所以我决定坚持使用这个工具。）CSS Stats 最酷的一点是它提供了关于网站 CSS 的健康状况和质量以及设计系统的清晰信息。它通过显示唯一 font-size 和唯一 background-color CSS 声明的数量以及特定 CSS 文件的 特异性图表 来实现这一点。

我首先想更好地理解我们的 manifest.css 文件。正如我提到的，这个文件包含我们所有的实用程序类（例如 padding-top-10px 和 c-salt-500）以及我们的 normalize 和 reset CSS 文件，因此它对于其他所有内容都是非常基础的。我开始深入研究 结果：

这里有一些明显的问题，例如存在 101 种独特的颜色和 115 种独特的背景色。为什么这是一个大问题？好吧，这对我来说有点令人震惊，因为我们的团队已经创建了一组 Sass 函数来输出一个非常特定的颜色数量。在我们的 Figma UI 工具包和 variables_color.scss（它被编译到我们的 manifest 文件中）中，我们总共声明了 68 种独特的颜色

那么，这些额外的颜色来自哪里呢？我认为它们来自 Bootstrap。在我们开始构建应用程序时，我们在 Bootstrap 的样式之上仓促地构建，没有在过程中进行重构。当我们在应用程序中发现视觉不一致以及数百行代码仅仅覆盖了 Bootstrap 时，这种情况开始变得痛苦。在一个相当英勇的 CSS 重构中，我从我们的主应用程序中删除了 Bootstrap 的 CSS，并将它存档到 manifest.css 中，等待着有一天我们可以回到它并重构它。

这些额外的颜色可能来自那个旧的 Bootstrap 文件，但可能值得进一步调查。无论如何，对我来说，真正的问题是 **我对设计系统的理解与前端的理解不同**。这是一个大问题！如果我对设计系统的理解与 CSS 的工作方式不同，那么工程师和设计师就有很大的可能采用错误的模式，并且混淆会蔓延到整个组织。想想额外的膨胀和缺乏可维护性，更不用说其他影响了。

我正在阅读 Matthew Ström 撰写的 设计系统面向谁？，当他引用了 Julie Ann-Horvath 的演讲时，我引起了注意，她被认为说：“设计系统只有在生产中才存在。”遵循这种逻辑，很明显我以为我们拥有的设计系统实际上并不存在。

回到 manifest.css，这个文件的特异性图表应该完全是逐渐的，然而却有一些明显的峰值表明可能需要重构一些 CSS 代码

接下来是我们的 components.css。请记住，这是我们组件样式来自的文件，因此我事先认为它一定会比我们的 manifest 文件更混乱。将它扔到 CSS Stats 中会返回以下内容

CSS-Stats 显示了一些相同的问题——例如字体大小过多（那个巨大的字体大小到底是怎么回事？）——但也有太多自定义颜色和背景颜色。在我开始之前，我已经对这个 CSS 文件最大的问题有所预感，我认为这个问题在这个数据中根本没有显示出来。

让我解释一下。

我们的大量组件曾经是某种形式的 Bootstrap 文件。例如，我们的 Accordion.jsx React 组件。它导入一个 accordion.css 文件，该文件随后与所有其他组件的 CSS 编译成一个 components.css 文件。这样做的问题是，一些 Accordion 样式会影响比该组件本身更多的东西。来自这个文件的 CSS 会渗透到其他模式和类中，而这些模式和类并不仅仅与一个组件绑定。这有点像我们系统中的毒药，会影响我们的团队，因为它使得难以可靠地更改单个组件。它还会导致一个非常脆弱的代码库。

所以我想说的是，像 CSS Stats 这样的工具对于帮助我们检查 CSS 健康状况的核心生命体征非常有用，但我认为它们永远不会真正捕捉到全貌。

接下来是 app.css 文件

这是我们的设计系统团队目前正在努力理解并希望重构为一系列灵活且可维护的 React 组件的“巨石”——这些组件可以被其他人反复重用。

让我担心这个代码库的是它的特异性。当 manifest.css 或我们的 components.css 中发生更改时会发生什么？这些样式会被巨石中的样式覆盖吗？我们导入到新项目中的漂亮整洁的组件样式会发生什么？

随后，我不知道我从哪里偷来的，但我最近一直在说这句话——你应该总是能够预测你的 CSS 会做什么，无论是单行代码还是一个巨大的交织在一起的样式代码库。这就是设计系统的全部意义——为未来设计和构建可预测的界面。如果我们的编译后的 CSS 中包含所有这些不可预测且不可知的部分，那么我们需要召集大家一起解决它。

总之，我将其中一些数据扔到一个 Dropbox Paper 文档中，确保我们开始解决这些问题，并随着时间的推移逐渐改进。今天看起来像这样

您是如何进行 CSS 审计的？您的团队是否进行 CSS 代码审查？您有什么建议的技巧和提示吗？请在下方留言！