就要开始新的项目了，全站的前端架构也要开始构思，得益于之前做雅虎关系时的一些或成功或失败的实践总结，还是应当从架构的层面着手，去解决一些前端团队开发的问题。如今市面上有着各种各样的js库和框架，但库和框架还是有很大区别的，首先，“库”是widget的一个集合，特点是上手容易使用简便，参照例子只大概只需要引用一个script标签到页面中，再加上一些简单的类似a.start（config）的启动代码就可以了，而框架则是网站的树状结构的抽象，包括模块关系，功能之间的依赖，入口的先后顺序，以及性能的hack等等，幸运的是阿里还是很明智的选择了yui作为其前端架构的底层，只是由于yui2强大丰富的widget库，使得多数人认为yui2更是一个库而非框架，而yui2的yuiloader也仅仅是一个可选的模块，这样就更加淡化了yui2在框架层面灵活强大的表现力，个人认为如果网站没有以yuiloader搭建起来的模块树做支撑，yui2的作用无疑是一把牛刀只用作杀鸡而已。在yui3中，这种情况有了根本改变，框架层面的模块化代替了简单的库，这对于团队开发的大型网站是很有启发的。

当然，在做前端开发的时候，使用loader必然要多写几行代码，多几次封装，又麻烦又不方便，这样做到底好在什么地方呢。这个话题大概说来话长，这里只从网站规模和项目特点的方面来作简单说明：

像taobao这种大型的网站，前端开发占有不小的比重，这类网站一般会按照大类划分成不同的产品，每个产品相当于一个独立完整的网站，只有整体样式风格和组件会和主战保持一致。

那么从web前端角度讲，这类网站大致包含四部分内容：

1），网站下辖站点所需的全局变量和函数，包括所有子站共通的部分

2），子站外框（公共头尾）

3），网页主体内容

4），组件

根据三者的特点，各自的重用情况为：

1），全站的全局变量和函数：几乎每个页面都要用到

2），子站外框：几乎每个子站的网页都保持一致

3），网页的主体内容，不可重用

4），组件：重用率高，但是被有选择的调用，只在必要的时候才会引用组件

从需求的角度上讲，这类网站的特点是更新频繁，从工程的角度讲，代码的维护成本大于甚至远远大于代码开发成本。也就是说项目随着时间的推移，修改功能的项目数量要远远大于新功能的开发，到项目的中后期，工程师的大部分时间不是写新代码，而是花大量的经历去读旧代码，或者进行性能优化，或者针对新需求进行改进。不管是性能改进还是需求改进，都将增加代码的熵，代码污染也会越来越严重，维护成本也会急剧变大，这让项目后期开发工程师苦不堪言，有一部分原因是项目前期文档不全，缺少写代码的必要的约束和约定，再者是注释不够及时和规范，导致代码可读性差，三是工程师水平参差不齐，有些人在修改代码过程中会无意识的破坏原有代码的结构，四是时间压力导致代码质量下降，五是框架结构的不合理。

完善文档和规范、增加新人培训力度可以以解决一部分问题，但这往往和制度和执行力度有关。从项目生命周期来看，项目分为叠代和快速开发，快速开发是开发时间短，不需要和其他项目并行，及时开发及时测试及时打包上线，和其他项目发生冲突的可能性很小，简单迭代的开发模式是基于分支和主干的多线程的并行开发。在此基础上的前端开发也是保持和后段开发同步的迭代。迭代的优点是项目并行和减少冲突的发生。从后端开发的角度看，经常多人开发同一个页面，只是每个工程师负责的模块不同而已，一般情况下页面中只有include的入口，然后调用各自工程师的代码，这样在页面中的代码污染就比较低，但是随着页面复杂度的增加，后段代码会越来越多的直接出现在页面当中，比如使用更多的echo代替模版，html代码中嵌套更多的if判断和for循环。这样会增加代码污染的程度。从前端开发来看，也会经常出现多人合作开发同一个页面，也是每人负责不同的功能模块，这里有两种情况，1是多人同时开发不同的应用模块，两者没有依赖关系，2是多人分别开发框架和应用，两者之间有依赖关系，应用依赖框架。而两者之间的耦合应当仅仅以入口调用作为接口，因此前端框架应当考虑到这种情况，即多人开发的前端功能代码应当尽可能地分离。

在js代码的写法上，自然推荐将代码都封装到页面的js文件中，在page中只留出入口。然而实际情况并非如此，在缺少框架约束的情况下，多数人不会选择去在读懂之前的烂代码的基础上再添加自己的代码，通常会直接用最简单粗暴的用script标签引一个js，紧跟着开一段script代码块写启动入口，甚至于连script标签都烂的写，直接在原先代码块中直接开辟一段区域自己加代码。这种做法应当如何看待呢？从库的角度讲，库中给了很多模块的实例，使用模块的方式大都也是手写一个script标签引一个js文件，然后再页面中添加启动入口。那么当多人开发同一个页面中的不同功能的时候就会这样做：