最近几天，公司留出部分时间来给开发做一次完全的梳理与重构计划，于是也总算有时间来梳理一下前端的东西。
我试图从整体的框架上，来描述清楚我们当前前端项目结构及作业方式。一是让自己清晰；二是让其他协作的同事，或者后进的同事有一个概览性质的东西来了解我们的框架结构。
下面我主要通过这五个方面来描述：
1、工程化结构；
2、模块化结构及实现；
3、MVC实现；
4、页面渲染逻辑；
5、版本管理方式；
6、项目间联系；
一，工程化结构
gulp做了大部分工程化，自动化的处理；webpack基本上就是做了文件加载器；
二，模块化结构及实现
左边三个块是我们模块化实现的基础，po_to是我们之前的同事自己编写的一个前端框架，一直作为我们前端的主力框架在使用。
三，MVC实现
四、页面渲染逻辑
此前，我们引入了nodejs作为中间层，来合并请求，组装数据，渲染页面返回客户端；前些天我们认为node鸡肋之后，希望快速的抽调node这一层，于是把原有的node服务直接改装成了静态的线上资源服务，从而快速的达到了抽调node的目的；但是也造成了问题，就是目前我们客户端请求发起，服务端装载页面并返回的过程有些曲折而奇葩；就是将我们的代码分别部署在了两个服务中；一个作为静态资源服务，一个作为控制器服务。
还有一点，图例没有描述的，就是客户端页面渲染的方式。我们是前后端完全分离的方式，因此前端页面数据依赖异步请求来加载，然后渲染页面。为了防止数据没回来时，页面部分空缺或者需要考虑无数据状态的替代方案的问题，我们在页面初始化时只做了一个loading的界面，等数据完全返回页面渲染完成，才展示真正的页面。这么做好处是，页面展示会比较完整，一次性展示完成；缺点是，没有分批加载给用户的感觉快，速度上没有优势。这也是我们即将改进的地方。
五、版本管理方式
图一，是我们现有的版本管理策略；这么做的原因是，当我们想找到比较久之前的某些代码的时候，我们需要翻阅长长的commit列表去寻找；而且每一个成员对于commit的描述方式的不确定性，造成了找代码的困难。于是我们做成了现在这样分迭代版本的分支管理策略，保留每个版本分支，线上服务器在新功能上线时直接fetch，并切换到当前版本的分支。
图二，是我们即将改回的版本管理方式，也是我们之前使用过的经典而通用的分支管理策略。
一点感想：现有的方式其实在核心思路上跟即将改版的方式是相同的，只是说在线上切换分支这件事情让大家觉得很奇葩。我倒觉得在操作过程中没觉得太多不妥，不过需要在所有成员都明确规则的情况下。然后，线上切换确实也是有的怪怪的，线上环境应该尽量只做更新操作，不要处理其他的东西为好吧。
6、项目间联系
