理论不能指导实践，就是空谈；技术不能解决问题，就是鸡肋。

先来看看我们有什么问题

我们经常遇到的问题

每次开会，言必及CSS代码难以管理和维护，冗余代码多，耦合度高，修改的时候，只能不断提升css选择器的权重来覆盖，相当痛苦。

js：不能按照功能和业务来组织代码，到处都是 脚本引用， script标签插入，全局变量污染，维护难，还很容易产生bug。

以上问题不解决，它会像一颗毒瘤一样不断生长，扩散，重构势在必行。

但是在重构之前，有必要梳理一下导致今天这种局面的原因，对每一个原因进行深入分析，找到根源，采取对应的措施，才不会头痛医头。

表面上，原因有以下几点：

1、历史遗留问题

这个问题客观存在，但是...不重要的不细说。重要的是有没有意识到前人为什么把这么严重的问题留给了我们，答案其实也相当明了，因为css开发就是这样的，没有变量缓存，没有流程控制，能做的太少了，只能从头写到尾。css的这种问题几乎是普遍性的，很多大厂的大牛们也常常发文，怨声载道。

2、我们因为不敢动前人的代码，只能沿着这条道走到黑。

我刚来的时候，见过一个global.css文件代码有1000多行，现在它已经2000多行，接近3000行了，而且有好几个版本。它的膨胀过程大致是这样的：

一个新功能加进来，有一些公用样式要加进去或是要修改，但是文件实在太大，注释又不清楚，找不到原来的代码，只好在文件的末尾添加新的样式，提高权重覆盖掉之前的样式声明。页面一刷新，效果出来了，搞定！！！每次有功能修改或是新增，上面的过程就会重复一次。冗余代码越来越多，文件越来越膨胀。

如果只看到上面两点，不加思索的盲目推行重构，只是沿着前人走过的路再走一遍，新老员工一交替，我们这帮后人就会变成他们口中的前人，结果就是后人复怨后人矣！

稍作分析不难发现，对于css，我们不能按照功能或者业务来划分css模块，为了减少请求，一个页面所有的css样式全部写在一个文件里，后续即使有重大功能更新，也不会作新的版本，而是在原来的文件上增删改，时间一长不敢删和改了，只能增加覆盖，结果就是冗余，耦合。对于js，我们虽然使用了seajs，但是没有按照功能或者业务来划分模块，只是用到了其处理依赖加载模块的功能。

模块化的意义

模块化其实不仅仅是为了处理依赖，代码复用。它更应该是一种分而治之的编程思想，每个独立的功能或者业务划分为一个独立的模块，暴露的接口可以被应用程序调用，应用程序无需知道每个模块的具体实现。我们现在对seajs的使用有点为了用而用的感觉，没有解决问题。我常常能看到页面里多个script标签，各种模块和非模块化代码杂乱无章写在页面里。

如何应用模块化来重构

对于js，每个页面应该只有一个入口模块，其余的模块组件都在该入口模块内部实现依赖和加载，模块应该按照功能或者业务来划分，原则上一个模块，一个js文件。

这里有必要提到一个模板工具 artTemplate 以及为此开发的 编译工具 Tmod，这两个项目都已经在github上开源。

借助模板工具，我们可以不用在js里面用字符串拼接来生成DOM，让js专心处理交互逻辑，保持代码的可读性和可维护性。

artTemplate 的好处在于，你可以把要插入的DOM直接写入HTML文件而不是js文件，通过Tmod编译工具自动编译成js，并且支持cmd，amd输出。看一个教育经历模板的例子

教育经历会有多条，它可以通过include 来引入单条教育经历模板，编译成js，输出amd为自动为其处理依赖。输出的js文件是这样的(amd)

这个模块的最后 return 一个 template()方法，参数是我们要注入的数据， 暴露了一个可以供外面调用的接口，调用十分方便

var eduTemplate = require('edulist'),    // 加载教育经历模板        eduContainer.html(eduTemplate(data));  // 传入数据生成html代码块并且插入DOM

artTemplate 和 Tmod的地址在。

对于css：

这里我想讲一下sass， sass是css的一个预处理器(与之类似的还有less)， 以及流行很多年了。

sass可以让我们以写js的方式来写css，并且他支持引入局部文件，这里的局部文件我们可以当成sass模块或者组件

sass的主要特点：

1、可以声明变量，拿一个我们经常遇到的一个种场景：全站的按钮的颜色要从淡绿色变成深绿色，css你需要一个个找到替换，如果是全部还好，可以用编辑器的全局替换，如果是部分，那就只能呵呵了。用sass， 你只需要声明一个变量，给它赋值，以后所有的用到这个颜色的地方都使用这个变量，而不适用具体的颜色值。修改的时候只需要修改这个变量的值即可。

$globalBtnColor: lightgreen !default;.btn1{
         background-color: $globalBtnColor; }.btn2{
         background-color: $globalBtnColor; }

2、可以把一大段css样式封装成一个 mixin，要用的时候就可以像js函数一样调用一下就可以了，下面写一个清理浮动

@import "compass/reset";@mixin clearfix($supportIe:false){	@if ($supportIe){		*zoom: 1;	}	&:after{		content: '';		display: block;		clear: both;	}}#wrapper{	@include clearfix();}

上面的代码，clearfix还支持传入参数，如果你要支持ie6， 可以传入true，生成的css会有一个针对ie6的hack，该参数默认为false，既不支持ie6

3、可以引入局部文件，你可以把组件的样式单独写在一个sass文件，要引入的时候只要 @import "yourfilename.scss"; 编译之后的css文件就会包含组件的样式

上面我引入了3个文件，global.scss , datePicker.scss , dialog.scss ; 分别将全局，时间组件， 弹窗组件的样式引入， 编译之后只有一个css文件， 无需理会css文件里的内容， 维护的时候只要维护对应的sass文件即可。

这样，我们的css模块化也就是可行的了， 我们可以把页面上的css拆分成独立的模块， 头部 header.scss,  尾部 footer.scss,  筛选 filter.scss. 最后在主题的sass文件中全部导入， 以后换了头部 我们只要维护 header.scss文件即可， 分而治之的好处尽显....

sass还有很多很强大的功能，不一一列举，感兴趣的童鞋可以google一下， 相关的文档和社区都有很完善的使用指南。

使用模块化必须要谈的是构建，模块化可以让我们用单独的文件来组织管理我们的代码，但是如果不进行处理，就会造成页面加载请求数量过多，页面加载缓慢。通过构建可以将模块打包成一个文件，并且实现代码压缩，减少体积。

常用的构建工具有：grunt(这货我刚学会用它好像就已经过时了)，gulp，webpeck....

 

最后...

前端是一个新的领域，也是一个快速发展(快的让人蒙圈)的领域，有人提出了一个前端摩尔定理： 前端每18个月难一倍。不学习就会被甩掉好几条街啊..

本人才疏学浅，有错误的地方还请指正