没那么难，谈没那么难，谈CSS的设计模式的设计模式
什么是设计模式？
曾有人调侃，设计模式是工程师用于跟别人显摆的，显得高大上；也曾有人这么说，不是设计模式没用，是你还没有到能懂
它，会用它的时候。
先来看一下比较官方的解释：”设计模式（Design pattern）是一套被反复使用、多数人知晓的、经过分类的、代码设计经验的
总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。 毫无疑问，设计模式于己于他人于系
统都是多赢的；设计模式使代码编制真正工程化；设计模式是软件工程的基石脉络，如同大厦的结构一样。”
今天我们来聊聊CSS的设计模式。
设计模式，这个词汇我们常见，几乎所有的编程语言都会有几套，但深入研究的人不多，原因如下：
1、似乎没有太大必要性去强调它，有问题了改一下或者按团队规范来就行；
2、不去使用一些既有的模式也无伤大雅；
3、不少人所接触的业务量级还没有达到需要规划和组织的程度，光写布局，写特效，照顾兼容，就够喝一壶的了，没有意识
去思考一些方法论的问题。
当然，这三者都是我经历过的，相信你也是~
我们都会长大，都会慢慢的做更多、更大、更复杂的项目，这个时候，就需要自上而下，全流程的去思考一些问题，后台不
说，只讲前端，比如：风格的制定、色调、模块、布局方式、交互方式、逻辑等等，如果再加上团队合作，若再没有一个规划
的话，要不了多久，那些看起来没问题的代码，就会暴露出各种问题，模块命名、类的命名、文件的组织、共用模块的提取、
代码的复用、可读性、扩展性、维护性。它们看起来只是一些简单的小动作，却需要你看得更远，避免将来出问题需要付出更
大的代价，甚至被迫整个项目重构，可谓，功在当代，利在千秋~
既然要对CSS进行设计，那么肯定是它本身存在一些问题或者缺陷，其中，一个最明显的就是，它的任何一个规则，都是全
局性的声明，会对引入它的页面当中所有相关元素起作用，不管那是不是你想要的。而独立及可组合的模块是一个可维护系统
的关键所在。下面，我们就从多个层面来探讨一下，到底该怎样写CSS，才是更科学的。
从需求出发
分
我们刚开始学习写字的时候，是不会去考虑，写出来的某句话好不好，文章结构合适不合适，因为我们是意识不到的。写代码
也一样，刚开始，我们只是去定义规则，能用对了属性，语法正确，把页面实现出来了，就好。慢慢地，就会发现，页面也是
有结构的，我们按照页面的结构去组织代码，会不会更好？比如，分成头部、导航、侧边栏、banner区、主内容区、底部
等。
然而这样貌似还是不够，因为还有一些东西，复用度是很高的，又不好把它归为任何一个固有模块，比如：面包屑、分页、弹
窗等，它们不适合被放到某一个固有模块的代码中，就可以单独的分出一段专属的css和js，或许，这就是组件化的由来~
拆
在分了之后，我们的代码看起来已经比之前好很多了，组织清晰，维护性大幅提高，但是，好像还是不够，我们会发现另外一
些东西，很细小，但复用度也很高，它们同样不适合被放到模块中去，比如，边框、背景、图标、字体、边距、布局方式等
等。如果我们在每个需要它们的地方，都定义一次，它们会被重复很多次，显然，这背离好的实践，会造成代码冗余和维护困
难。所以，我们需要“拆”。拆过之后会怎样？我们想在哪里用可以直接加，需要改的时候统一改。
排
经过了“分”、“拆”，我们的代码结构已经十分清晰，各个内容模块，功能模块，UI模块都乖巧的等待召唤，那么还差什么？是
的，还差有序的组织，分类清晰之后，还需要排列有序，从不同纬度去考量，我们总能精益求精。举个栗子，我们可能会看到
像这样：
@import “mod_reset.css”;
@import “ico_sprite.css”;
@import “mod_btns.css”;
@import “header.css”;
@import “mod_tab.css”;
@import “footer.css”;
我们将不同的部分按照一 定的顺序去摆放，能让我们的代码看起来更加有序，易于维护，同时，有利于进行继承或层叠覆
盖。不要小看这一步，看似可有可无，实际要求比较高的统筹规划能力，可以减少冗余代码和快速定位问题位置等。
除此之外，我们依然可以有其他的方法来帮助我们进行区分代码范围，比如：
资源评论
