css 架构

1. 我理想中的css架构；
2. 现如今项目中css维护存在的问题；
3. 自动化工具的选择；
4. 文件结构与命名规范。

1. 我理想中的css架构

可预见的、可重用的、可维护的和可扩展的

可预见的CSS

可预见性的css意味着你的规则行为正如你所想，当你添加或更新一条规则，他不应该影响你网站上不想要受影响的部分。对于一个小型网站很少的修改，并不是很重要。但是对于一个有着几十或几百个页面的大型网站，可预见性的css就是一种必要。

可重用性的CSS

css规范应该是足够抽象的和耦合的，这样你可以根据现有代码部分很快创建出新的组件，而不需要重新编写你已经处理过的样式和问题。

可维护的CSS

当你的网站需要添加、更新或重新安排一些新的组件和特性，这样做不应该重构现有的css。给页面添加x组件不应该破坏已经存在的组件Y。

可扩展性的CSS

随着你的网站的规模和复杂程度的增长，它往往需要更多的开发人员来维护。可扩展的css意味着可以轻松的由一个人或一个大型的技术团队管理你的网站。它也意味着你的网站的css架构容易掌握，思路清晰，容易把控，不需要高学习成本，因为你是如今唯一接触这个网站css的开发人员，但是并不意味着永远是这种情况。

2. 现如今项目中css维护存在的问题；

现项目是 ICID 数据系统平台，是使用 sass + webpack 开发， 选用 bootstrap css框架作为辅助开发 css 的，由于还处于开发初始阶段，暂时还没有出现很多维护的问题，但随着页面的增加，由于搭建阶段时间紧凑加上自己项目经验的缺乏，前期 css 架构搭建的潜在问题仍然较多：

• css reset 里其实有很多代码是不必要的，像*{}的这种写法是不可取的；
• 项目漏写CSS通用样式库，导致页面 css 代码冗余量很大。所谓CSS通用样式库就是可以在任何网站使用的CSS样式库，某种意义上讲，CSS库与js库属于类似的东西。
• 网站CSS样式库不完善，导致 css 可重用性与可维护性差，开发效率低。网站CSS样式库是指根据当前实际项目内容制定的，复用性高的，例如，网站常用的背景样式，边框样式，文字样式，以及一些高宽等。

3. 自动化工具的选择

目前主流的自动化构建工具大致有grunt、gulp、FIS、webpack等。
具体就不做介绍了，因为大家都懂了。
众多构建工具如同雨后春笋，没有好与不好，存在肯定有它的价值，选择适合自己业务场景的工具是最实际的。
对于开发 ICID 项目，css 开发方面，我的需求很简单：

• 首先，css 模块化，提高代码复用性，也能让资源文件更合理地进行缓存；
• 其次，项目文件配置简单，每次项目启动简便，提高开发效率；
• 最后，就是要有一个能实时编译，方便本地开发调试的服务。

webpack 就符合我所需。
并不是说其他工具就不适合，可以说 我刚好需要，而你刚好在 吧。

4. 文件结构与命名规范

--|sass
----|common
----|fonts
----|layout
----|page
----|vendor
----stylr.scss

我的命名规范一般如下：

• 样式命名用 class，JS 命名用 id；
• 然后分为布局、模块、部件、功能、状态等：

如：

布局（layout）

文档  document  简写 doc  
头部  header   
主体  wrapper   简写 wraper
主栏  main  
侧栏  side    
...

模块（module）

导航         nav  
面包屑       crumb  
手风琴       accordion     简写 acd  
图文混合列表  picture-text  简写 pic-txt  
...

状态（status）

选中  selected  简写 slt  
当前  current  
触发  active    简写 act  
...

以上是我之前整理的笔记一部分举例。 个人认为 css 的命名不能使用特定的关键字。如，标题使用 title，如果项目引入的插件也使用 title 命名，那么就会产生冲突，这个 css 的可预见性就不高了
还有一种就是模块+命名的方式的命名，当然这能有效的防止样式冲突，但是随着嵌套层越多，越细分，命名就会很长，可读性并不高。