文档介绍：中小型项目前端架构
一、为什么要有一个好的架构
首先明确一点,架构是为需求服务的。前端架构存在的目的,就我个人理解来说,有以下几点:
1. 提高代码的可读性
一个好的架构,代码的可读性一定是很强的。
简单来说,假如有一个新人加入团队,那么他接手这个项目,一定是容易上手的,能简单轻松的了解整个前端部分的相互关系,从而找到自己需要重点关注的点。而不是需要花很多时间去熟悉这个项目的很多细节,才能开始上手做东西。
就文件来说,可以从文件名上,分清哪些是页面、哪些是逻辑、哪些是样式、哪些是可以复用的组件、哪些是图标组、又有哪些是移动端或是PC端专享的样式/逻辑等。
就代码来说,包括统一的命名风格,封装在同一个文件里的代码的相关性足够强等。
2. 提高代码的可维护性
一个好的架构,一定是易于维护的,例如在新增需求、更改需求、修正bug,都不会造成意料之外的变化,比如说修改了一个页面组件的内容,却导致另外一个页面组件发生变化(这也太坑了)。因此,要低耦合,高内聚,以及输入和输出是可预期的。
3. 提高代码的可扩展性
一个好的架构,一定扩展性要强,不能写死。
需求变更太TM正常了,新增需求也太TM正常了。因此好的架构,必须要考虑到这些情况的发生,因为这些是一定会发生的。所以,一定要避免把代码写死。
比如页面组件A里需要有一个日历组件,而这个日历组件引用的是别人的(比如从github上找的)。那么尽量不要直接在页面组件A里面直接引用这个日历组件,而是将写一个日历组件B,在这个日历组件B里封装你引用的日历组件C,然后通过这个日历组件B来进行操作。
原因很简单,假如某天产品经理说,这个日历组件太丑了,我们换一个吧。如果你直接在页面组件A里内嵌这个引用的日历组件C,你很可能就要改很多代码(因为不同日历组件的使用方法和暴露的接口可能不同)。假如你还在其他多个地方引用了这个日历组件,那就更糟糕了!每个地方都要改。
而若是将引用的日历组件C封装到自己写的日历组件B之中,那么你只需要改日历组件B里的相应代码即可,而因为日历组件B暴露的接口是不变的,那么自然不用修改页面中的代码了。
附图,以日历组件为例,是否考虑到扩展性的结果
未考虑到扩展性:
考虑到扩展性: 
4. 便于协同
包括前端和后端的协同,前端和前端之间的协同。
具体来说,前后端的协同通常是以ajax为交互,那么应至少有一个用于专门封装了所有ajax请求的文件,所有ajax请求都封装在这里。在开发时,这里封装的方法应该可以模拟发送和接收约定好的交互内容,方便开发联调。
而前端和前端的协同,主要体现在同时在更改代码时,不会影响对方代码的正常运行。因此要求封装、解耦以及低干扰度是必须的。
5. 自动化
自动打包,压缩,混淆,如果有必要,再加上自动单元测试。
总结:总结来说,一个好的架构的目的是,让前端写代码写的舒服,让后端联调的舒服,让产品经理改需求改的舒服。
二、我如何设计架构
我不敢说自己的架构是好的架构(显然不是啦),只能分享自己最近做的一个项目,它的架构的如何做的。
首先,确定需求:
1、一个中小型网站,同时面向移动端和PC端(单端大概15个页面,算上弹窗大约20个);
2、预算有限(给的钱少),开发时间有限(一个月);
3、可能存在一定程度上的需求变更(比如增加页面或修改某些页面内容);
4、客户可能不太在乎优化(但是我自己在乎啊);
5、要求兼容IE9以上。
其次开始决定:
1、兼容IE9以上说明可以使用主流框架,而无需必须使用jQuery。因此我采用了vue,;
2、预算有限,时间有限,因此PC端和移动端共html和js,独立css;
3、页面有限,因此无需将架构层级划分的比较细,只需要按其类型划分即可;
4、根据原型图来看,页面复杂程度有限,复用部分不是很多,因此可以确定哪些东西需要封装复用,哪些比较复杂需要独立封装,哪些比较简单为了简化开发难度可以直接耦合;
5、自己比较熟练单页面网站,因此采用以单页面为主,异步加载其他页面的形式。
于是使用相关配套的东西,比如webpack,vue-router等,另外为了开发和生产的方便性,采用以下模式进行开发。 
第三,划分功能:
首先有一个根html,用户需要通过访问它来加载我们的js逻辑,。
,我们的前端代码可以被划分为三部分:
组件树
功能模块
各种资源
如下图: 
功能划分好之后,相同功能的放在同一个文件夹下,命名风格应该类似。
具体来说,组件树相关的东西,,ponents文件夹下;资源,有图片或者国际化资源等,,