前段时间出了好几起因为css改动影响其他应用的故障。想想也是，网站已经10年，从table时代一路走来，style目录上的文件早已混乱不堪。不看内容，光是目录结构和文件的命名就已经让人犯晕。于是准备在Q1对style文件进行整理规划，大致有两个想法。

第一点、style文件（包含css和javascript）应该是分层级的。试想下如果谁都可以改动全站的框架js那会有多大的风险！这里我们把style分为三级：

第1级：全站性。 这一类文件是全站通用的，主要是框架fdevlib。文件的修改权在前端架构组这边，任何的应用都不应该修改这一级别的文件。架构组负责对该类文件的更新和维护。ps：这个做法对我们网站还有一个隐问题。因为widget组件很多都是来自各产品线的一线开发而不是架构组专人来开发维护，所以我们还需要一套完备的入库审核机制。

第2级：产品线级。根据前端代码的依赖关系把网站划分成近10条产品线，每条产品线的代码相对对立，并为每条产品线指定owner。owener负责整理本产品线的style文件，规划出1到3个左右本产品线公用的样式和脚本。这些文件的维护权在owener手里，一般的应用应该在这些文件的基础上进行扩展。毫无疑问，在第二级的样式文件里可以做更多的东西。比如嵌入产品线独特的展示方式、皮肤、业务逻辑等等……

第3级：应用级。这些文件的权限应该是开放的。因为网站的产品互相穿插胶着，一个前端可能需要涉及多个产品线，为了避免冲突，应该在1、2及框架的约束下进行扩展开发、重载。没有特殊的情况绝对不能修改1、2级的文件。确保多人开发的情况下不会互相影响。

层级关系示例图如下：

第二点、页面style文件的引用规划：

按照网站目前的做法，比较重要的页面都是采用服务器端merge的方式将调用的css或是js合并在1个文件中。比如目前 中文站首页 底部的”http://style.china.alibaba.com/js/homepage/index1001/merge/index-bottom.js”这个脚本。在发布之前它的实际内容是import了多个js：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

/*merge start*/
(function(){
	ImportJavscript = {
		url:function(url){
			document.write("<script src=\""+url+"\"></scr"+"ipt>");
		}
	}
})();
/*merge end*/
ImportJavscript.url("http://style.china.alibaba.com/****/fdev-min.js");
ImportJavscript.url("http://style.china.alibaba.com/****/get-min.js");
ImportJavscript.url("http://style.china.alibaba.com/****/animation-min.js");
ImportJavscript.url("http://style.china.alibaba.com****/fdev-tab-min.js");
ImportJavscript.url("http://style.china.alibaba.com/****/fdev-marquee-min.js");
ImportJavscript.url("http://style.china.alibaba.com/****/fdev-alitalk-v3.js");
ImportJavscript.url("http://style.china.alibaba.com/****/done-min.js");

好处显而易见，可以减少http请求数。但是实际维护起来的成本却比较大。一方面每次新增需要merge的脚本时都要修改这个文件；另一方面很多公用的脚本比如框架性质的fdev.js都没有被缓存。

怎么改进？拿js来说，基于上面规划的style文件分级体系。我们首先将1级的框架类脚本merge起来，生成一个 http://style.china.alibaba.com/cache/aliframe.js 作为全站统一的缓存资源。其次需要对每条产品线建立一个merge的js，比如http://style.china.alibaba.com/cache/frame-list.js，它里面import了aliframe.js和list所属的2级公用js。 最后对这些脚本目录设置一个相对较长的缓存时间。这样一来，对于简单的非产品线属页面，只要引aiframe.js文件后再引入页面特有的脚本即可。而对于产品线属页面也只需要引入相应的js（比如frame-list.js）后再添加应用级的脚本。一般情况下的改动只需要修改第3级的应用类脚本，不需要动到已缓存的页面。这样既降低了维护成本，新增脚本时不需要再改动已经merge的脚本文件，又通过缓存提高了页面的加载速度。所增加了一个http请求还是值得的。

说完，最后感慨一下：前端的发展速度的确是快。07年底中文站一共才6个前端开发，而到09年底的时候这个数字包含外包已经达到22个了。07年前绝大多数需求还是上传图片、切割页面之类的小任务而现在前端已经深入到业务的核心模块。在快速扩张的同时如何发挥出团队的整体作战力达到1+1>2的效果，大家可以一起来探讨下。

来源：http://f2e.me/archives/188