这是我参与更文挑战的第2天,活动详情查看: 更文挑战
一、前言
昨天一个朋友问:我的工作只有vue、react,了解其他的好像没有太大作用。其实不然,前端要考虑的内容其实很多,不光是完成业务代码。
我司的一个控制台前端维护人数在20+,如果每个人都在一个项目中开发,那么每天就等着构建了,不仅容易出错,而且浪费时间,这对于线上项目是不可容忍的。
前端项目有大有小,这里假设我们面对的是一个相对复杂的中台系统,那么要考虑的东西是很多的。下面我列举了大部分,如果有缺失欢迎小伙伴补充。
下面列举的内容包含了必须的模块,比如框架选型,接口调用,公共组件
有些是可选的模块,比如各种规范约束,单元测试,多语言支持、模拟数据
还有一些是随着系统的变大需要增加的,比如版本管理、灰度系统、自动构建部署、页面监控,质量测试,数据监控等。
有一些是多人合作,提升效率的,比如前端CICD部署、微前端服务器
二、内容总览
- 1、基础设施
- 1.1、文档规范
- 1.1.1、接口文档
- 1.1.2、开发文档
- 1.2、代码规范
- 1.2.1、Gitlab、git分支提交规范
- 1.2.2、tsconfig (ts配置)
- 1.2.3、eslint 代码质量
- 1.2.4、pritter代码格式化
- 1.2.5、css规范
- 1.2.5.1、重置浏览器样式
- 1.2.5.2、兼容内容
- 1.2.6、项目目录规范
- 1.2.7、版本管理规范
- 1.2.8、接口规范
- 1.2.9、工具类函数和变量规范
- 1.2.10、注释规范
- 1.2.11、项目环境配置(开发、生产、测试)
- 1.2.12、皮肤主题切换、语言切换
- 1.3、常用技术
- webpack
- mock
- 状态管理
- 1.4、ui组件库
- 1.5、cli脚手架
- 2、开发阶段
- 2.1、技术选型
- 2.1.1、微前端框架
- 2.1.2、js库选型
- 2.1.3、路由、导航规范
- 2.2、主要模块
- 2.2.1、权限系统
- 2.2.2、公用组件管理
- 2.2.3、页面框架
- 2.3、代码质量
- 2.3.1、单元测试
- 2.3.2、代码质量检测
- 2.3.3、关键页面性能分析
- 2.4、文件、图片懒加载
- 2.5、其他
- 2.5.1、反向代理配置
- 2.5.2、模拟数据
- 2.5.3、引入路径配置
- 3、部署阶段
- 3.1、项目环境区分
- 3.2、自动化部署
- 3.3.1、shell脚本
- 3.3.2、CI/CD
- 3.3.3、代理、缓存配置、代码压缩
- 3.1、灰度系统
- 3.4、回退方案
- 3.5、容灾方案
- 3.6、CDN
- 4、监控阶段
- 4.1、前端js报错监控
- 4.2、页面访问统计系统
- 4.3、特殊页面埋点
复制代码
三、基础设施
1.1、文档规范
那句话咋说来着:研发最讨厌的就是写文档,最喜欢的就是别人写文档
对于前后端分离开发来说,文档是很重要的。
没有文档,大大增加了沟通成本,而且后期问题确认,维护都会很困难。
但后端又忙的没有时间写文档,所以更多的时候最少可以通过自动化手段生成文档,比如我这边开发Golang服务、Node服务会使用Swagger生成文档,对于工期紧张的项目,当然也可以通过Postman分享给前端,这样对于双方都可以减轻负担。
开发文档,可以帮助开发理清思路,记录开发过程中困难,当然你的项目天天十万火急,就当我没说。
1.2、代码管理
代码管理,对公司而言,一般直接使用Gitlab就行了,搭建成本也很低,权限控制、自动发布等很完善了,当然一定要备份。
通过Gitlab,设置管理员权限,其他的角色可以分配可读,可合并,可发布等权限。
为了代码的干净整洁,更好的维护,代码格式化,代码质量,初始化样式、目录规范、接口规范、注释规范、工具类函数规范等都是要提前确定好的,防止后面越写越乱。
当然项目更新频繁,还要考虑版本管理
项目有国外的用户,需要配置语言切换。
换肤效果也是很多网站会需要的。
一个项目一般由一个人或多人开发,涉及到不同的功能,不同的人员,那么Git就是你必须要考虑的。涉及到多人管理,还会存在分支管理的问题,如果不同的人随便搞,容易造成代码混乱,所以在开发项目之前要制定Git代码分支管理规范。
Git分支提交规范,如何区分提交内容,是bug、新功能、优化还是其他。如果定义好,对于之后的历史查找会方便很多
1.3、其他
前端项目mock数据引入,方便前端调试和独立开发。
如果公司的项目规模比较大,可能需要自建UI组件库,配置CLI脚手架,去方便组员拉取代码
很多人不写代码注释,我也不喜欢写,但注释也是代码的一部分,没有好的注释,一些业务要不了多久再看,就会一头雾水,所以注释能写尽量写,磨刀不误砍柴工。
//
原则上空一格,单行注释
/**/
如果多行注释可以使用这种方法,每个文件开头可以使用的注释格式有:
文件开头一般写上:
作者:
日期:
描述:
复制代码
上面是一些建议的规范,当然优秀的程序员要懒
,可以直接使用插件,生成注释,然后使用eslint去规范注释的格式,这样就可以保证项目中注释的规范。
缺点是:增加了开发的成本,拖慢项目速度。如果你天天赶工期,还是把eslint禁了吧,写完早点回家看看其他公司的机会。
四、开发阶段
2.1、技术选型
现在我开发使用比较多的是,前后端分离的单页应用,这里我们就以这种后台为引,默认前后端分离。
考虑技术选型,其实Vue和React已经几乎能满足所有的公司了,就算需要高度SEO,也有很多解决方案。
微前端,是必须要考虑的一个环节,如果项目划分成了很多产品,每个产品都有对应的需求,想要所有的项目汇总在一个平台,那么微前端绝对是不二的选择,实现方案也比较多,可以选择最合适的。
路由、导航都建议提取配置文件,可以让项目更好的管理。
一个好的目录结构,应该是职责分明的。每个目录做对应的事情,公用组件文件夹,工具函数文件、页面路由文件、状态管理文件等。
2.2、后台的常见模块
1、大多数后台都需要权限管理,然后根据每个员工的角色不同,看到不同的内容,那么就要求前端做好权限管理模块的规划,提取公用配置,进行单独管理
2、公共组件,很多需求都是可以复用的,提高组件的复用性,可以减少代码量,提高系统性能。
2.3、代码质量
本是同根生,相煎何太急。需求实现就行了,干啥这样?
但对于生产环境的项目来说,少一个bug就多一个客户,所以为了保障线上的稳定,这里有很多方案去解决。
上线前的单元测试,部署代码分析系统来分析页面的代码质量。对于关键的页面还要进行针对的分析,查看加载速度,访问数据等等
五、部署阶段
3.1、打包部署
项目部署,可以很简单,也可以很复杂,具体取决于自身需求。
如果简单的可以通过shell脚本处理,复杂一点的可以通过CICD+K8S构建。
3.2、打包不同的环境
我们的项目基本不会只部署生产环境,常常需要部署测试环境,那么我们常见的做法是通过配置环境变量来控制打包。
3.3、灰度系统
项目上线前要考虑,出现问题怎么及时挽救,这里我们就要考虑,要怎么实现灰度方案,在全面部署前,先灰度一部分用户,就像手机软件常常要求你体验抢鲜版,确保基本没问题,在正式部署。
3.4、版本回退
一个项目在发布出现问题后,必须要有回退的能力。这样当遇到问题时,可以及时的进行代码的回滚操作,保证线上稳定。
3.5、容灾
自然灾害谁也料不到,如果单点部署我们的业务,一旦云服务商一个机房出现问题或虚机宕机,必然影响到业务,所以要考虑负载均衡,多节点部署。
3.6、CDN
大访问量的网站,如果广州的客户请求部署在北京机房的服务,那么打开速度必要会慢,在广州买台服务器却没有必要,这时候选择CDN,通过一个个节点,减轻服务器压力,让用户打开速度更快。
六、监控阶段
想像一下,如果你打开一个网站,前端报错,这时候页面卡死,作为开发其实是看不到的,那么就无法解决这个问题,可能用户就直接关了这个页面,不再访问了。这样肯定是不行的,我们可以通过监控系统,去收集这些错误,及时解决这些bug,比如开源软件sentry
用户是通过什么渠道进入你的页面的,你的页面每天的访问量是多少?我们可以通过统计系统分析日志请求,来汇总这些信息,常见的有百度统计。
对于一些重要的页面,也需要增加标记,记录访问用户,一旦恶意请求,可以及时屏蔽,比如goaccess分析nginx日志。
七、最后
当然这其中很多都是一些规范问题,对于小项目来说,考虑的不多;
对于大项目来说,很多内容也都是只需要一次配置,也有一些方案是根据项目发展来配置的,比如灰度系统的实现方案。
以上是我现在可以考虑到的方面,不足的方面希望各位可以补充下。