当前公司前端架构及技术说明

最近几天,公司留出部分时间来给开发做一次完全的梳理与重构计划,于是也总算有时间来梳理一下前端的东西。
我试图从整体的框架上,来描述清楚我们当前前端项目结构及作业方式。一是让自己清晰;二是让其他协作的同事,或者后进的同事有一个概览性质的东西来了解我们的框架结构。

下面我主要通过这五个方面来描述:
1、工程化结构;
2、模块化结构及实现;
3、MVC实现;
4、页面渲染逻辑;
5、版本管理方式;
6、项目间联系;


一,工程化结构


当前公司前端架构及技术说明_第1张图片
工程化结构及技术栈示意图

gulp做了大部分工程化,自动化的处理;webpack基本上就是做了文件加载器;

二,模块化结构及实现


当前公司前端架构及技术说明_第2张图片
目录结构及模块间联系

左边三个块是我们模块化实现的基础,po_to是我们之前的同事自己编写的一个前端框架,一直作为我们前端的主力框架在使用。

三,MVC实现


当前公司前端架构及技术说明_第3张图片
mvc模型示意图

四、页面渲染逻辑


当前公司前端架构及技术说明_第4张图片
服务端页面组装方式

此前,我们引入了nodejs作为中间层,来合并请求,组装数据,渲染页面返回客户端;前些天我们认为node鸡肋之后,希望快速的抽调node这一层,于是把原有的node服务直接改装成了静态的线上资源服务,从而快速的达到了抽调node的目的;但是也造成了问题,就是目前我们客户端请求发起,服务端装载页面并返回的过程有些曲折而奇葩;就是将我们的代码分别部署在了两个服务中;一个作为静态资源服务,一个作为控制器服务。

还有一点,图例没有描述的,就是客户端页面渲染的方式。我们是前后端完全分离的方式,因此前端页面数据依赖异步请求来加载,然后渲染页面。为了防止数据没回来时,页面部分空缺或者需要考虑无数据状态的替代方案的问题,我们在页面初始化时只做了一个loading的界面,等数据完全返回页面渲染完成,才展示真正的页面。这么做好处是,页面展示会比较完整,一次性展示完成;缺点是,没有分批加载给用户的感觉快,速度上没有优势。这也是我们即将改进的地方。

五、版本管理方式

当前公司前端架构及技术说明_第5张图片
现有的分支管理策略


当前公司前端架构及技术说明_第6张图片
即将变成这样的


图一,是我们现有的版本管理策略;这么做的原因是,当我们想找到比较久之前的某些代码的时候,我们需要翻阅长长的commit列表去寻找;而且每一个成员对于commit的描述方式的不确定性,造成了找代码的困难。于是我们做成了现在这样分迭代版本的分支管理策略,保留每个版本分支,线上服务器在新功能上线时直接fetch,并切换到当前版本的分支。

图二,是我们即将改回的版本管理方式,也是我们之前使用过的经典而通用的分支管理策略。

一点感想:现有的方式其实在核心思路上跟即将改版的方式是相同的,只是说在线上切换分支这件事情让大家觉得很奇葩。我倒觉得在操作过程中没觉得太多不妥,不过需要在所有成员都明确规则的情况下。然后,线上切换确实也是有的怪怪的,线上环境应该尽量只做更新操作,不要处理其他的东西为好吧。

6、项目间联系


当前公司前端架构及技术说明_第7张图片

你可能感兴趣的:(当前公司前端架构及技术说明)