前言

在做项目的过程中，我发现尽管还原出来了原型图上的要求，但是css代码一直都是一大坨的扔在了<style>标签里面，让人根本没有想看的欲望。尤其是，最近的一次项目中突然加了个换肤的需求，看着自己之前写的css样式，甚至产生了跑路的想法。（游戏中的屎山也不过如此了吧 =.=）最后en是用js给重新替换了，也懒得写其他css代码了。

用我的话来说的话，我一直都在写一次性代码。所以，如何去提高自己代码的可维护性被提到了日程上，计划从Css开始，正好最近也在学Sass，先把“一次性代码”的臭习惯给改掉！

后面也会逐步思考怎样写出优质的js、vue代码（性能上、可维护性上等），本篇主要以开发可维护性强的css思路为主，代码部分可能偏少，希望能耐心看完给出建议！
废话多也是建议，直接评论就行，咱皮厚 0.0

使用Sass（★）

没学过Sass的前端人我觉得真的太难了，有了Sass能省下不少功夫，尤其是对于css代码的维护与编写上。

Sass是Css的一个预处理器，添加了一些很方便的特性，比如：
变量、嵌套、导入、混合、函数、for循环、if判断、运算等等，可以看做把css向js靠拢了一点。

既然在写前端，难免会遇见各种各样的颜色啊，字号啊，背景啊这些很多需要重复声明的属性，而这些东西一旦改起来也是大海捞针一般，尤其是在写完项目过了很长时间之后。

而这时，一旦有了变量存在，一切烦恼都烟消云散了。我们只需要新建一个Sass文件，在里面放上一些公共的样式即可，需要的时候直接@import导入就能够使用我们在这个文件定义的变量了。

我们可以声明一个主题色，以及与其对应的各种按钮及文字颜色，当需要更改时，我们只需在主题文件（或颜色文件）中做些处理，做到牵一发而动全身。

写过Css的都知道变量的出现意味着什么，维护一个变量和维护一堆字符串肯定选变量

构建一个良好的文件结构（★）

之前写css都是一个文件代码直接拉满，现在想想真的是初生牛犊不怕虎，完全没有考虑到后期维护或者需求增加、变更的可能性。
换句话说，js、vue、node都模块化了，css还不往上面靠靠合适吗？

vue3组合式Api不知道算不算模块化，感觉有些类似，但是核心思路都差不多，将功能相近代码或逻辑的抽出来，做到指哪打哪

7-1模式（不是7减1，是7杠1）

所谓7-1模式，就是将控制css代码相关的文件分成了七个文件夹，最后分块通过 import 引入到一个 main.scss 文件中，该文件放到根目录，以达到分工明确，逻辑清晰的目的。

7个文件夹

base: 该文件中，放置所有的样板代码。这里说的样板文件，是指每次你开始一个新项目时，你要写的所有 CSS 代码。例如：排版规则，动画特效，公共工具(这里的公共工具是指如margin-right-large, text-center,…)等等。
components: 该命名已经指明了其地位。此文件包含用于构建页面所需的组件，如：buttons、forms、swipers、popups等等。
layout: 用于布局页面的不同部分。即：header、footer、navigation、section、grid等。
pages: 有时候你可能写了一个页面，但要为其制定专属的样式，所以你把这种专属样式放置在 pages 文件夹中。
themes: 如果你的 app 需要拥有不同的主题(黑暗主题，默认主题等等) ，把这些主题放置在该文件夹中。
abstracts: 把你的所有函数，连同变量和mixins一起放置在这里面，简言之，就是放置所有的助手。
vendors: 有什么 app 或项目不依赖于外部库吗？将那些不依赖与你自己写的样式文件防治站该文件夹中。你可能想在这里面添加 Font Awesome 文件、Bootstrap 等等类似文件。

1个main.scss

@import abstracts/variables;
@import abstracts/functions;
@import base/reset;
@import base/typography;
@import base/utilities;
@import components/button;
@import components/form;
@import components/user-navigation;
@import layout/header;
@import layout/footer;

其中@import是Sass的语法格式，用于导入其他的scss文件，导入后就能直接使用在其内定义的变量了，不同于Css的什么时候用什么时候加载，Sass是直接加载。

代码块没有scss/sass格式的，凑合着用css吧
上面的创建并非固定的，可以根据自身项目的大小自行调整文件结构

css分类方法

通过用途或性质将css分为几个大类

公共型样式
- 对于比较小的项目，我们只引入一个css，这个css的样式即公共型样式，多用于：
  - 消除浏览器的默认样式（这方面网上有大佬写的现成的代码，不用自己写）
  - 统一调用背景图和清除浮动或其他需统一处理的长样式
  - 网站通用布局
  - 通用模块和其扩展
  - 元件和其扩展
  - 功能类样式
  - 皮肤类样式
特殊型样式
- 对某个维护率较高的栏目或者某个与网站整体差异较大的页面独立引入这样一个特殊型样式
皮肤型样式
- 说白了就是放颜色放背景的
重置和默认的css代码
- 消除默认样式和浏览器的差异，以减少后面的重复劳动
统一处理的css代码
- 统一调用背景图和清除浮动（指通用性较高的布局、模块、原件内的清楚）

我们可以按照上述规则建立目录，也能够实现上述7-1模式的效果

规范的Css命名（★）

维护代码的前提是能看懂代码。见名知意已经提过无数次了，但是区别于其他语言，css的命名含义具有很高的重复性，像.warp1、warp2或是nav-top、nav-left这种很容易出现。但是自己写自己看还能稍微翻译翻译，但凡是换个人没冲过来揍我我就谢天谢地了。更别提还有偷懒没写注释的地方了。所以一个合理的命名，或者说一个统一的规范就显得尤为重要。

在此我搜了两个方案，供学习

并不确定是否为普及高的方案。不过真的进公司的话应该内部有自己的统一规范吧？

BEM 命名

命名: 块元素名称或元素名称 + -- + 修饰符名称
简单来说就是 组件_内部细节--这个组件或其内部细节长什么样子

块
通常指组件，例如一个card或者一个form

元素
是“块”的一部分，它们是建造“块“的必需品。可以理解为一个组件中的细节部分，例如按钮、文本、数字等等，.card_date、.form_author

修饰符
用于描述该块或元素。可以理解为你想实现的效果长什么样子。.card_date--red、.post__btn--disabled

注意点

使用 BEM 时，命名只有 class 类名并且只使用 class 类名，没有 id ，没有标签，就只使用 class 类名。
块/元素可以嵌套到其它块/元素中，但它们必须是完全独立的
- 写出来的card_btn--left没人知道left是相对谁的，耦合度贼高，没有独立
BEM会使HTML变的臃肿，还是看更注重什么吧，取决于个人，我认为是优大于劣。