你知道如何写出易维护的整洁的 CSS 代码吗？要想写出易读易理解易维护的 CSS 代码，你只需掌握一些简单的方法就够了！今天你将会学习其中五个，我们将会讨论文件结构，混合的 CSS 和 JavaScript 及其劣势，还有如何更好地给 CSS 添加前缀以及自动执行，最后我们将学习如何处理技术债务。那么，让我们来学习如何写出整洁的 CSS 代码吧！
内容列表：
简介
No.1: 坚持一种命名规范
良好的有意义的 CSS 类名
语义化命名规范之美
No.2: 使用外链样式表文件
No.3: 验证 CSS 代码
火的淬炼
No.4: 使用 CSS 代码 linter
No.5: 采用模块化的 CSS 代码
如何选择模块化框架
简介
本文中有许多方法可以称得上写出整洁的 CSS 代码的第一要务，同时也可能有一些你不想使用的方法。因此很难决定哪个方法最重要，也很难对这 10 个方法进行排序。考虑良久并重排了多次之后，我决定把这个问题留给你们。在这个只有两部分的迷你系列的文章中，我仅仅是展示给你们写出整洁的 CSS 代码的 10 个简单的方法而已。
我以一种既定的顺序把这些方法展示给你，这是按照理论上每个方法所需的知识量来排序的。换句话说，前面的方法会比后面的方法容易实现。然而，这种顺序也不是一成不变的。很可能你会在排序或者方法内容上与我产生分歧，因此你可以把它想象成餐台并各取所需。
如果你发现了美味佳肴，拿走不谢，否则跳过然后继续。所有这些书写整洁的 CSS 代码的方法都基于十年来我从事的网站设计工作的经验。如果你在实践中另有所得，你完全可以有不同的见解，但请不要不加尝试地否定它。一些方法没有生效的话，请试试其他方法，或者反其道而行之，最起码你应该尝试一下。没时间啰嗦了，快上车~
No.1: 坚持一种命名规范
你考虑过该如何创建 CSS 类和 ID（请尽量避免 ID）吗？我不是指一闪而过的念头，而是花费若干时间来深度思考。当然，我假设你使用 CSS 是迫于工作，也许你并不想把写代码搞的多么有哲理。另外还可能有些人将 CSS 视如芒刺在背，找个借口赶快写完然后去做更有趣的事情，对吧？
别担心，我不是来说服你使用 CSS 是一件多简单的事情。如果你不喜欢它，那也是你的选择。然而，我会试着说服你尝试一些其他方法，你可能经常使用 CSS，那么怎样把它变得有趣一点呢？你只需思考如何实现良好的命名规范，然后坚持下去。为什么要这样做呢？这会让你的 CSS 代码变得更具可读性。
理解了 CSS 代码，你就能更高效地书写和使用它，也更容易写出整洁的 CSS 代码，过程也就不会那么痛苦了。也就是说，好的命名规范就等于容易理解的 CSS 代码，你将向整洁的 CSS 代码迈近了一步，而远离了使用 CSS 代码的痛苦。听起来很简单是吗？那么问题来了，良好的有意义的命名规范长什么样呢？
良好的有意义的 CSS 类名
我觉得良好的或者有意义的命名规范很容易辨认。当看到样式表内容的时候，你就能大致了解这段代码所控制的元素，这也可以用来测试你写的代码有多整洁。你是否需要查看 HTML 代码或者加载网站才能理解 CSS 代码？果真如此，我认为你的 CSS 代码还不够整洁，至少还有进步的空间。简言之，良好的有意义的命名规范应具有描述性。
整洁的 CSS 代码中没有基于某人天马行空的想象而命名的类。如果你想发挥自己的想象力，我建议你用在其他地方。确实，以你最喜欢的书或者电影命名的类并不会造成危险，但你在酩酊大醉或者磕了药的时候修改密码就非常糟糕了，一时心血来潮起的类名与此如出一辙，因此这并不是书写整洁的 CSS 代码的正确方法。如果别人并不了解你所写的书或者电影，读你的代码简直就像读火星文一样。并且，万一你发现了另外一本好书或者好电影，你还要换类名吗？
当然，你可以按自己的喜好改变而重写所有的 CSS 代码，但是这既不高效也让人无法忍受。通常来说 CSS 或者其他任何代码都必须要如洪荒宇宙一般经得住时间的考验，其复杂性也要如此。因此最好的办法是尽快开始书写整洁的 CSS 代码，最好是从一开始就这样。如果你现在还一头雾水，那就一个月之后再回过头来看这篇文章。除了凭借想象力命名，你可以使用哪些其他的命名规范呢？
语义化命名规范之美
易实现且有助于写出整洁的 CSS 代码的命名规范都是基于语义化的，简言之，类名应当可以清楚地描述其控制的元素。你用过 Bootstrap 或者 Foundation 框架吗？去看一下他们的文档你就能明白什么是语义化的类名，比如：breadcrumb、btn、dropdown、jumbotron、pagination 或者 nav。你不用查看 HTML 代码也不用加载网站就能明白这些类名的含义。
同样，这种方法也可以用于通过类名改变状态的元素。这种情况下类名应当描述其作用，比如：btn-raised 表明按钮凸起，btn-disabled 表明按钮失效，sidebar-left 表明侧边栏在左边，nav-primary 和 nav-secondary 清楚地说明了导航的重要级。
你需要照抄这些类名才能写出整洁的 CSS 代码吗？不，你可以使用自己的命名规范去创建类名。你必须要牢记类名必须具有描述性，要让其他的网站设计开发人员无需与你沟通 ，也无需查看代码或网站就能够读懂你的 CSS 代码。如果你自我感觉良好，那么让其他人来看一下你的 CSS 代码，结果可能会令你大吃一惊。
关于命名规范和书写整洁的 CSS 代码，我最后想要提醒的事情就是当你选择了自己的命名规范之后要坚持下去。最好将一种命名规范应用到所有的项目中，这会让你适应原来的项目，并且在新项目中如有神助，因为你不必每次都去琢磨起名字的事情了。我最喜欢的命名规范是啥？是 BEM！
No.2: 使用外链样式表文件
对许多网站设计开发者来说这是秃子头上的虱子——明摆着的事情，但是我认为提示一下总是有益无害的。你的大部分 CSS 样式都应该在外链样式表中，为什么是大部分而不是全部呢？根据谷歌对于优化 CSS 传输的建议，少量内联的 CSS 代码是有好处的。问题是，哪些是少量的可内联的 CSS 代码呢？有一些关键的样式，请戳这里查看。
除了这些关键的 CSS 样式你可以写在 head 标签内或者小的 CSS 样式文件中，其他都应当写在主要的外链样式表文件中。要注意，外链文件需要经过压缩处理来优化网站的性能。
只写一个主要的外链样式表文件有助于书写整洁的 CSS 代码，原因有二：第一，所有的 CSS 代码都集中在一个文件内，有助于 CSS 文件的管理，不太可能会漏掉引入某个文件。第二个原因主要是心理上的，你很难对那些突然映入眼帘的乱糟糟的 CSS 文件视而不见。在写那些小的 CSS 样式文件的时候，你会觉得它们是有顺序的，只有当所有的文件都整理到一起的时候，你才会发现那真是一团乱麻。只写一个外链的 CSS 样式表文件能迫使你关注自己的 CSS 代码。谁会愿意翻几百行的代码去改一点点内容呢？更不要说你可能根本没在用那些样式。一段时间之后，你就会决定停止这种写很多文件的荒唐的做法，并做出些改变。值得庆幸，这会是好事，比如你会花时间将一团糟的 CSS 代码整理得整洁有序，即重构你的 CSS 代码。最后，一个样式表文件可以助你保持你的 CSS DRY，你节省的每一行甚至每一个 kB 都是好事。
No.3: 验证 CSS 代码
又一个无脑的建议哈？如果你想写整洁的 CSS ，你应该确保代码生效。如果这真的非常简单，那为什么网页设计开发者中很少有人使用验证服务来检查他们的 CSS 代码呢？
不管怎么说，除了维护整洁的 CSS 代码还有两个使用 CSS 验证的理由。
第一，这很容易确保你向客户端传送了完美的内容，客户端当然不大可能会验证 CSS 代码。你不会知道验证的结果将会如何，并且这仅仅是确保你的工作完美无瑕。验证器只需几秒钟时间去分析 CSS 代码，如果没有问题或者警告，你可以奖励自己一朵大红花。但是如果出现了问题或者警告呢？太棒了！这是你提高工作水平和代码质量的好机会！当你思考的时候，你就在走上坡路了！整个过程中，你要么通过了验证，要么学到了新东西，何乐而不为呢？
火的淬炼
接下来是我们使用 CSS 验证器的第二个理由，你可以发现自己的弱项、发现自己的错误，然后改正错误并将弱项巩固成强项。你将再次向整洁的 CSS 迈近了一步。我想强调一件事情，验证器并不能用来评判你的优劣，时刻记住它只是个工具。所以，无论结果如何都不要太往心里去。
上文提到，使用验证器跑一下 CSS 代码有利无害，你要么通过测试要么学到所需的知识。现在我要修正一下，还有一种情况是失败的，那就是你忽视结果并决定不再学习如何做得更加出色。其他的任何情况对你而言都是胜利。
我们还有一些心理上的坎要过，比如我们害怕技能测试。上学的时候，考试不及格是非常糟糕的事情，拿到一个 F 简直就是世界末日。为什么要这样呢？如我所言每一次测试都是机会，你能发现自己不擅长的东西并且巩固它，不然如果连自己的弱项都不知道，又怎么能巩固它呢？这么说来，验证器是否正中你的要害？是的！打开 Google 找到你的代码哪里出错了，为什么会错，你也可以在 Stack Overlow 上寻找最佳答案。记住，变的优秀的唯一的办法就是不断学习和巩固你的弱项。
No.4: 使用 CSS linter
你是不是觉得使用验证器就像是打了鸡血一样？或者像是搏击俱乐部的 Tyler Durden？那么我来给你介绍一个叫做 CSSlint 的东西。如果你认为 CSS 验证器正中你的要害并且有点伤感情，那就尝试一下这个工具吧。
这两者有什么区别吗？验证器只会提示你无效的代码，即被反对或没有完全实现的代码、语法错误以及不支持的元素。另一方面，linter 就显得更加主观一些。基于可以自定义的规则，它能提示许多被验证器忽略的内容，通常 linter 用来检测错误、重复的样式、性能、兼容性和可及性的问题。一旦你违反了规则，linter 都会有提示。我觉得使用 linter 更容易写出整洁的 CSS 代码。你也可以只使用验证器，事实上我关注的一些 CSS 最佳实践都是基于 CSS lint 的。
你记得我们第一次讨论过的 CSS 最佳实践吗？如果你关注了这些内容，你可以使用 linter 测试一下，比如你可以测试关键元素的使用、ID 和过时的元素。Linter 的好处就在于你可以自己选择要检查的规则，比如你想使用 box-sizing（谁不想呢？），就把该条规则禁用掉。记住，linter 应该助你写出整洁的 CSS 代码，而不是给你造成麻烦。
同样要记住 CSS linter 中的规则并不是一成不变的，也没有人人都要关注的最佳实践。因此我建议你使用 linter 之前，按照需要自定义设置，如果你不喜欢一些规则，不要使用就是了。
No.5: 采用模块化的 CSS 代码
第五个方法中，我们将接触更高级一点的书写整洁的 CSS 代码的方法。为什么要 CSS 代码模块化？真的有必要吗？我先回答第一个问题，CSS 代码模块化有助于我们构建和识别 CSS 样式，也有助于实现 DRY CSS。换句话说，它让你更容易写出整洁的 CSS 代码。模块化 CSS 潜在的不利因素就是需要使用预处理器，我使用的是 Sass。
你可以书写原生的 CSS 代码并将其模块化，使用预处理器的好处就是能够切分 CSS 代码，你可以分别存储每一个代码块文件，然后在一个单独的样式表文件中将其引入。这属于管理代码的范畴了，因此并不是 CSS 代码模块化的必须方式。CSS 代码模块化是指书写可重用的代码，你将创造能够用于任何位置的模块而不用书写更多代码，这能优化性能也有利于网站维护。
我们可以花一整天的时间来讨论各种各样的框架，然而这并不是本文的目的。另外本文也已经够长了，我尽可能地长话短说。最后，有许多模块化的 CSS 框架，你可以用来书写整洁的 CSS 代码。因此……
如何选择模块化框架
最重要的问题来了，哪个才是最好的框架呢？我的答案是没有。根本就没有最好一说，实现方法和需求因人而异。适用于我的框架也许并不适合你，另外你也可以博采众长创造一个新的框架。因此我建议你尝试多个框架，并找到适合你的那个。
拿我自己举个例子吧。我决定使用模块化的 CSS 代码的时候，刚开始使用的是 SMACSS，这个框架简单易学容易实现，基于对 CSS 代码的五种分类，即基础代码、布局、模块、状态和主题，需要学习的就是如何识别 CSS 代码的分类。你对 SMACSS 感兴趣吗？最好的学习方法是阅读官方文档，官网地址。
由于 SMACSS 的性能很好，我很长一段时间都在使用它。但是当我发现 Atomic design 的时候，我决定要上升一个档次。Atomic design 也是基于五个分类，即原子、分子、物体、模板和页面，也清楚地说明了每个特定的 CSS 样式所属的分类。我最喜欢将 Atomic design 和 BEM 一起使用，并用在了所有的项目中。你想学习更多内容吗？我给你推荐两个资源。
第一个就是 Atomic design 的官网，介绍的地非常深入，因此你需要时间来消化。第二个就是利用 Atomic design 书写可扩展的 & 模块化的 CSS 代码指南，这个文章会帮助你学习如何利用 Atomic design 快速书写模块化 CSS 代码的所有内容。BTW，我在博客上也发布过这篇指南。除了 SMACSS 和 Atomic design，我还会介绍至少两个更流行的框架来书写模块化和整洁的 CSS 代码。
一个是 Object Oriented CSS 也称 OOCSS。它将代码块视作可重用的对象，这仍然是模块化 CSS 代码，因此它的工作原理类似 SMACSS 和 Atomic design。我以前用过所以可以介绍地更多，请查看 GitHub 上的文档或者这篇 Smashing Magazine 上的说明。
第二个是新出的 ITCSS，其基于七个层——设置层、工具层、一般层、元素层、对象层、组件层和最高层。ITCSS 乍看之下稍有难度，其实不然，一旦你理解了规则和思路使用起来非常简单。如果你对 ITCSS 感兴趣，欢迎查看 ITCSS 全方位简介。模块化 CSS 的框架千千万，但弱水三千只取一瓢，今天讨论的这些足够你起步了，我希望能尽快帮助你写出整洁的 CSS 代码，而不是将你淹没在可能的选项中。
No.6: 整理你的文件结构
保持文件结构的简洁
如何在单个文件中构建你的 CSS 代码
No.7: 让 CSS 和 JaceScript 代码分离
为什么混合的 CSS 和 JavaScript 是大忌？
如何更聪明地使用 CSS 和 JavaScript？
No.8: 留心供应商的前缀和后备方案
避免臃肿的 CSS 代码
No.9: 让供应商更容易维护，自动执行
N0.10: 管理你的技术债务
No.6: 整理你的文件结构
我们在第一部分讨论了模块化的 CSS 代码，在继续学习下一个方法之前，我们应当简单地讨论一下文件结构。从自身出发，模块化 CSS 代码非常有用，然而可能你习惯将所有的 CSS 代码放入一个样式表文件，那么它很快就会变得无法控制。比如说，从单个样式表文件到十个或者二十个文件那就有如天壤之别了。我们来看写下面这个例子，这是 ITCSS 中的文件结构：
例:
@import "settings.colors"; @import "settings.global"; @import "tools.mixins"; @import "normalize-scss/normalize.scss"; @import "generic.reset"; @import "generic.box-sizing"; @import "generic.shared"; @import "elements.headings"; @import "elements.hr"; @import "elements.forms"; @import "elements.links"; @import "elements.lists"; @import "elements.page"; @import "elements.quotes"; @import "elements.tables"; @import "objects.animations"; @import "objects.drawer"; @import "objects.list-bare"; @import "objects.media"; @import "objects.layout"; @import "objects.overlays"; @import "components.404"; @import "components.about"; @import "components.archive"; @import "components.avatars"; @import "components.blog-post"; @import "components.buttons"; @import "components.callout"; @import "components.clients"; @import "components.comments"; @import "components.contact"; @import "components.cta"; @import "components.faq"; @import "components.features"; @import "components.footer"; @import "components.forms"; @import "components.header"; @import "components.headings"; @import "components.hero"; @import "components.jobs"; @import "components.legal-nav"; @import "components.main-cta"; @import "components.main-nav"; @import "components.newsletter"; @import "components.page-title"; @import "components.pagination"; @import "components.post-teaser"; @import "components.process"; @import "components.quote-banner"; @import "components.offices"; @import "components.sec-nav"; @import "components.services"; @import "components.share-buttons"; @import "components.social-media"; @import "components.team"; @import "components.testimonials"; @import "components.topbar"; @import "components.reasons"; @import "components.wordpress"; @import "components.work-list"; @import "components.work-detail"; @import "vendor.prism"; @import "trumps.clearfix"; @import "trumps.utilities"; @import "healthcheck";
上面的例子中包含了 65(!) 个文件，如果这都不算超出了控制，告诉我什么才是！65 个文件，即使对网站的设计开发的老鸟来说也已经非常多了。如果你是个新手，这看上去简直是疯了！当然，这个例子比较特别，文件的数量和你选取的方法有关。然而，项目伊始你需要记住，你应该提前为项目规划文件结构，而不要等到火烧眉毛了才着急。
保持文件结构的简洁
我建议两件事情，第一，保持文件结构简洁，第二，找到有效内容。你没必要非得使用上例中的方法，我相信构造模块化 CSS 的关键之一就是因人而异。不一定非要按部就班，你可以随心所欲地改变方法。另外，你也可以自由地组合使用多个框架，比如：第一部分中讲述了我综合使用了 Atomic design 和 BEM 和少量的 SMACSS 这三种框架的例子。
你也可以和我一样！如果你喜欢框架 A 也喜欢框架 B，不一定非要二选一，你可以取二者之长来使用。这也同样适用于文件结构，你可以想用文件夹就用文件夹，不想用就干脆不用。其实，用文件夹可能会好一点，这样有助于文件管理。然而，用还是不用由你决定，只需要保证你用起来舒服就好。来看一个例子，这是我在某个项目中使用的文件结构：
例:
// Project imports // Import settings @import '_settings/config'; // Import tools @import '_tools/functions'; @import '_tools/mixins'; // Import base @import '_base/normalize'; @import '_base/base'; @import '_base/typography'; // Import atoms @import '_atoms/animations'; @import '_atoms/buttons'; @import '_atoms/inputs'; @import '_atoms/inserts'; @import '_atoms/labels'; @import '_atoms/links'; // Import molecules @import '_molecules/forms'; @import '_molecules/gallery'; @import '_molecules/jumbotron'; @import '_molecules/navigation'; @import '_molecules/pagination'; @import '_molecules/parallax'; @import '_molecules/slider'; // Import organisms @import '_organisms/footer'; @import '_organisms/grid'; @import '_organisms/header'; @import '_organisms/sections'; // Import pages @import '_pages/404'; @import '_pages/about'; @import '_pages/contact'; @import '_pages/homepage'; @import '_pages/prices'; @import '_pages/faq'; // Import templates @import '_templates/print';
如你所见，我喜欢使用文件夹使框架中各个层相互独立，我也喜欢让文件结构相对第一个 ITCSS 的例子保持简单。要记得，我之所以这样用是因为这很适合我，如果你喜欢其他的方法，那就用其他的方法，如果不喜欢某个方法就不要用。我们的目标是使用有意义的结构避免啰嗦的代码，而代码啰嗦是书写整洁的 CSS 代码最大的阻碍之一。整洁的 CSS 代码就是 DRY CSS。
如何在单个文件中构建你的 CSS 代码
我们要讨论的最后一个问题就是如何在单个文件中构建你的 CSS 代码结构。此时此刻，我们假定你没有使用任何的预处理器，因为事实上你没必要去用它。使用预处理器并不会帮你写出好的整洁的 CSS 代码。这种情况非常流行，如果你的 CSS 代码很糟糕，预处理器通常只会雪上加霜而不是雪中送炭。因此，如果你决定使用预处理器，首先保证提高你的 CSS 编码技巧。
说一点次要的，组织 CSS 代码最简单的方式就是使用注释，这也是一个良好的实践。我在单个样式表文件中也会使用注释来组织代码，这样能使编译后的 CSS 代码更具可读性，不然将很难读懂引入内容的开始和结束位置。现在，我通常在工作流中使用两种注释，实际上我用了三种注释，但是第三种注释只在 Sass 中才使用，并且也不会将其编译成 CSS 代码。
这两种注释即单行和多行注释。我用多行注释来标注每一个引入的内容，换句话说，我使用这种注释作为每个引入文件的开始。然后，我会使用单行注释来标明某项内容的开始位置。那么第三种源于 Sass 的注释呢？我会用它记录一些琐事或者未完成的内容，这种注释只在开发中才有用，没必要写入生产环境。
例 1:
/** * Section heading */ /* Sub-section heading */
重申一下，你没必要使用相同样式的注释。注释有很多种，让我用几个实例来给你的想象力充满电。
例 2:
/* * === SECTION HEADING === */ /* * — Sub-section Heading — */
例 3:
/* ========================================================================== SECTION HEADING ========================================================================== */ /** * Sub-section Heading */
例 4:
/*************************** **************************** Section heading **************************** ***************************/ /*************************** Sub-section heading ***************************/
No.7: 让 CSS 和 JaceScript 代码分离
模块化的 CSS 代码和有效地使用注释能够很好地维护整洁的 CSS 代码。然而，如果你到处写 CSS 代码，这些方法一个也不会生效。什么意思？网站设计者经常在 JavaScript 代码中定义 CSS 样式，我认为这在使用 jQuery 或者其他 JacaScript 库的开发者中更为普遍。使用 jQuery 来改变 CSS 样式比使用 vanilla JavaScript 更简单迅速，然而，这并不意味着那是好事。
为什么混合的 CSS 和 JavaScript 是大忌？
混合的 CSS 和 JavaScript 代码的问题就是很容易被忽视。这和在若干个样式表中维护整洁的 CSS 代码不同，当添加了 JavaScript 文件，你只会给自己的工作添堵。如果你使用了 JavaScript 预处理器，那简直是在自讨苦吃。那么是不是应该不顾代价地避免杂糅的 CSS 和 JacaScript 代码呢？也许不必，如果你只需改动一两次或者改动很小，杂糅也没关系。
当你想要改动一两次某个属性时候，可以选择 JavaScript，但是我不建议你使用这种方法，也不建议修改很多的属性或者反复地修改内容。如果那样做，你将不得不重复写这些代码，其结果是你不会再有 DRY CSS，更不要说是整洁的 CSS 代码了。当然，你可以使用函数来实现，但是你需要兼顾有些设备可能会造成 JavaScript 代码阻塞的情况。
尽管生活在一个技术迭代迅速的时代，但是我们并不能百分百地依赖 JavaScript。想象一下其他很蠢或者自我感觉良好的事情，很可能有不用 JavaScript 的人访问你的网站。如果你的一些样式依赖于 JavaScript，它们将不会生效。因此，即使你不太关心代码的组织结构，写混合的 CSS 和 JavaScript 代码也不是一个好的方法。
如何更聪明地使用 CSS 和 JavaScript？
那么，问题来了，你有什么其他办法能够动态地改变 CSS 样式并且维护整洁的 CSS 代码呢？从在你的 CSS 样式表文件中定义新的类开始，之后根据需要使用 JavaScript 来给特定的元素添加或者删除类，这样你就可达到目的。你就没必要在 JavaScript 中写好多遍 CSS 代码了，也不用使用任何的函数来实现。但是仍存在一个问题，这不能帮你解决 JavaScript 阻塞或者失效的问题。
JavaScript 阻塞或者失效问题的解决办法依当时情况而定。但你可以创建一个后备方案，设备不支持 JavaScript 时该方案就会生效，支持 JavaScript 的时候，你再去掉后备方案中的类，并不再使用。特征检测库 Modernizr 工作原理与之类似，我曾经讨论过如何利用 Modernizr 实现特征检测和渐进式增长，请戳这里。有点跑题了。
那么来概括一下，为了书写整洁的 CSS 代码，我建议保持 CSS 和 JavaScript 代码分离。如果你需要动态改变样式，请使用 CSS 中的类，不要直接在 JavaScript 中改变样式。因为哪怕你的改变很微小或者仅仅改动了一次，都可能会引发异常。如果你在为无 JavaScript 的情况写后备方案的时候遇到了任何问题，都可以跟我说。
No.8: 留心供应商的前缀和后备方案
第八个书写整洁的 CSS 代码的方法是只使用有用的代码，这意味着你应该经常检查你的 CSS 代码并且移除老旧的供应商前缀和后备方案。我是使用 CSS 和 JavaScript 最新特性的忠实拥趸，是的，我喜欢去体验那些或多或少有着试验意味的技术。我认为网站设计和开发者都应该有勇气使用这些技术，并且不光是在开发环境中，也要在生产环境中使用。
然而，这也要求你在网站开发过程中学习更多合理的方法。你需要选择你的网站支持哪些浏览器，光是支持最新版的浏览器是不行的，你必须确保网站在很多浏览器上都可用。比如，我通常比较注重 IE11+、Google Chrome 49+、Firefox 49+ 和 Safari 9+ 浏览器的使用情况，我会在这些浏览器上测试项目并使用必要的前缀和后备方案。
这仅仅是过程中的一部分，还有一个就是在改变浏览器的用法并实现了一些新功能的时候重新访问网站。当一些浏览器淡出用户视野之后，你应该移除为其而写的前缀和后备方案。如果想维护整洁的 CSS 代码，你应该定期这样做，否则你的 CSS 代码将会变得臃肿，将会充斥着没用的代码，并且浏览器在实现的同时会忽视这些前缀内容。
避免臃肿的 CSS 代码
不幸的是，这些前缀还存在你的 CSS 代码里，并造成了比实际需要更多的代码。对小项目来说，这并不是问题，但如果你在一个体量庞大的项目中使用 CSS 代码，这些前缀会给样式表增加许多 kB。就性能而言，每个 kB 都锱铢必较。另外，越来越多的人在使用移动设备访问网站，并不是所有人的网速都很快。
矛盾的是，有些设备经常运行的浏览器需要所有的前缀内容，但是其网络状态却差到每个 kB 都举足轻重。于是，用户变得越来越没有耐心。我们学到了什么？你应该在开发过程中做到重复访问过时的前缀和后备方案并移除它们。这样，你就能维护整洁的 CSS 代码，网站也能获得很高的性能。你可以点击这里来查看更多网站维护的内容。
No.9: 让供应商更容易维护，自动执行
移除老旧的前缀对维护整洁的 CSS 代码是非常重要的，然而，要实现这个目的也是很痛苦的。谁会愿意每两个月就检查一遍代码并且手动移除过时的代码呢？估计没人愿意。幸运的是，已经有更好的替代方案啦，我们可以将这项任务“外包”出去。
有两种方法，第一个选择就是使用任务运行工具比如 Gulp、Grunt 或者 Webpack。这些任务运行工具可以使用类似于 autoprefixer 的插件，多亏了这个插件你才可以外包这些任务。当你在使用这个插件开展任务时，它只在必要的时候才添加前缀，它还可以检查样式表文件并移除过时的前缀。你只需运行任务即可。
第二个选择是使用名为 prefix-free 的小工具，它和 autoprefixer 还是有点点区别的。 如我们所谈到的，autoprefixer 和任务运行工具一同工作，比如后处理器。而当你想要使用 prefix-free 时，你需要在页面的头部或者尾部将其引入，它将会在网站加载的时候运行并添加必要的前缀。有什么负面影响吗？又多了一个外部资源并且增加了带宽呗！如果用户遇到了 JavaScript 代码阻塞或者失效呢？然而，这总比不添加前缀好吧，而且这也比学习使用任务运行工具简单多了。
想征求我的建议？因人而异！短期来看并且作为一个快速修复的方法，prefix-free 会是更好的选择。然而，我建议额外花一些时间去学习使用任务运行工具，这会让你学有所得。任务运行工具能够让你的生活变得简单让你的工作变得快捷。我最爱 Gulp了，你可以在 Gulp for Web Designers 这篇文章中学习如何使用它。
N0.10: 管理你的技术债务
我们来谈谈维护整洁的 CSS 代码的最后一个方法吧。你听过所谓的技术债务吗？每一次你为了解决问题而快速地 Hack 一些事情时，技术债务就发生了。当你使用容易实现的代码替代最全面的解决方案时，技术债务就增加了。它通常出现在一些需要快速移动和传输的项目中，换句话说，在初创公司中很常见。
技术债务的问题不在于你创造了它，而在于很多时候你根本没有那么多时间去完美地解决它。有时候为了立竿见影你不得不使用非常差劲的方案，比如：假使你或者别人发现了网站或者产品上的一个大问题，而且网站或产品已经上线了。然后你需要迅速修复，否则就会失去客户，结果就会造成技术债务。
如我所言，其问题不是发生了技术债务，真正的问题是你可能会忘记有这个东西。技术债务发生的时候，你应该只把它作为临时的解决方案。等到时间富裕的时候，你应该回过头来用更好的方法替换掉快速修复的方法。从长远上来看，你将能够维护整洁的 CSS 代码。
不幸的是，我无法准确告诉你如何减少技术债务的发生，解决方法取决于当时的情况。但是，我可以给你三条建议：第一，利用某种方式积累工作内容，每次你使用投机取巧的解决方案时都要新建一个任务，好记性不如烂笔头。第二，花费部分时间来重新查看这些工作，并逐个解决。不要让技术债务和任务的数量积累得太大，否则将超出控制你将无从下手。第三，定期重构你的 CSS 代码。通过保持 DRY CSS 来维护整洁的代码，减少重复的代码，做到一次书写多次调用。
写在文末
恭喜，你已经读完了第二部分，同时也读完了这个迷你系列的文章！我希望谈论的这十条建议能够帮助你写出整洁的 CSS 代码，也希望你能够长期维护好它。我来告诉你一个秘密，书写整洁的 CSS 代码根本没什么困难，难的是你能够一直保持 CSS 代码的整洁。如果不只你一个人在写 CSS 代码，那将变得更加困难，但是只要怀着良好的目的去写 CSS 代码，事情就会变得简单了。
