# 构建一个后台管理系统要考虑哪些内容

> 作者/来源: UCloud 运营管理员
> 发布时间: 2022-10-08T06:54:00.000Z
> 分类: 云主机
> 标签: CDN, 前端
> 原文链接: http://117.50.162.249:3000/yun/articles/2387

---

# 构建一个后台管理系统要考虑哪些内容

> 来源: https://www.ucloud.cn/yun/127956.html
> 作者: 社区管理员
> 发布日期: 发布于2022-10-08 14:54

## 一、前言

昨天一个朋友问：我的工作只有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日志。

## 七、最后

当然这其中很多都是一些规范问题，对于小项目来说，考虑的不多； 对于大项目来说，很多内容也都是只需要一次配置，也有一些方案是根据项目发展来配置的，比如灰度系统的实现方案。

以上是我现在可以考虑到的方面，不足的方面希望各位可以补充下。