CSS团队协作开发方式的思考

有效的团队协作开发，可以提高工作效率。但在实际的协作开发中情况并非总是这样一帆风顺，最常见的一种情况是当大家都完成各自负责的部分后需要进行集成时往往会让我们大费周章。如过您也有类似烦恼，下面是我对如何改善这一状况的思考，欢迎探讨交流。

一 模块化

模块化概念：

和模块化相关的一个概念就是样式作用域，作用域是模块化基本条件。样式作用域是一条样式规则可以影响的范围，在不同样式作用域中的同名.class可以互不影响。CSS模块就是把一些相关的样式定义同一个样式作用域中。

模块化优点：

模块化可以方便复用模块代码，可以减少复制黏贴产生重复代码，重复的代码不仅增加代码的可维护性同时也会增加文件尺寸，导致样式加载时间延长推迟页面渲染时间，对前端性能也会造成一定的影响。

模块化实现：

一般可以使用CSS的包含选择符定义样式作用域，一个样式模块应该尽量保证其独立性减少外部依赖，和页面中其他样式代码划清界线这样在另外一个项目需要同样的样式时才可以方便的拿来使用，尽量减少全局样式，属于模块的成员应该定义在属于模块的局部作用域内，这样在多人协作时模块化的代码可以有效降低样式冲突。

模块化可能的问题：

避免在一条样式规则中使用过多子作用域如：
.mod_name .sub_name .sub_name .sub_name .member{...}
如果一个页面中有非常多这样的样式，那样页面的大小会快速增加，违反了性能优化原则，增加了服务器到浏览器网络传输量。
可以把上面的规则改成类似这样：
.mod_name .member_parent_sub_name .member{...}
这样一方面把一条样式规则中包含的.class数量降低到了3个以内减少了页面尺寸，另一方面由于选择符变简单了也能提高浏览器解析CSS的效率。

二 性能问题：

除了上面那个需要注意的问题外。另外根据《高跟性能网站建设进阶指南》中所描述的，浏览器在解析一条css选择符的时是按照从右向左的顺序解析的，直到能够确定需要匹配的DOM元素，或者是解析到了选择符的最左边，对这条选择符符解析才算结束。所以我们应该让靠右边的选择符尽量保证具体。

三 可维护性问题：

为了降低CSS的维护成本，更容易读懂别人的CSS代码。在同一项目中应该确保CSS书写风格的一致性。例如.class或ID的命名风格、CSS规则书写顺序等。对于class或ID的命名风格如果有两个单词组成的class 或ID，常见的命名风格有驼峰大小写、使用“-”分隔、使用“_”分隔。具体使用哪一中可以跟团队成员习惯任选其一并且保持同一即可。对于CSS规则书写顺序我一般是先写影响文档流(常规流、浮动流、绝对/固定定位)的属性然后是盒模型属性接着是字体属性等等。另外一个团队如果有一套统一的规范的话也可以大大降低维护的复杂度。