这是我参与更文挑战的第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日志。
七、最后
当然这其中很多都是一些规范问题，对于小项目来说，考虑的不多； 对于大项目来说，很多内容也都是只需要一次配置，也有一些方案是根据项目发展来配置的，比如灰度系统的实现方案。
以上是我现在可以考虑到的方面，不足的方面希望各位可以补充下。
