旧后台的改造

公司维护的一个后台由于离职人员没有配合好交接工作，开发维护时存在很多问题：

随着需求的迭代，开发效率受到影响，所以我决定对这个后台进行改造.

改造前：

1.本地开发需要修改系统的host文件；

也可以使用以下软件进行修改，其实就是将本地的localhost改为相应的域名，然后访问

2.环境判断是根据域名

3.三种环境的登录方式各不一样

4.test分支和master分支差异较大，存在功能差异

5.存储令牌的方式根据环境不一样，开发和生产使用Cookie，测试环境使用localStorage；

6.各环境令牌格式不同，test环境是JWT令牌，dev和生产还是走三件套（time, token, uid）

6.不同环境的接口请求返回的数据结构不一致

测试环境返回的菜单路由是不含域名和协议的，生产和dev是包含域名和协议的

改造过程：

1.根据环境变量判断环境

需要修改本地host，来调试服务，就是因为这个项目之前设计不合理，使用域名来判断环境

vue-cli本身就提供了使用mode参数来覆盖默认模式

详情请看：cli.vuejs.org/zh/guide/mo...

改造前的命令

改造后的命令：

json 复制代码

"scripts": {
    "dev": "vue-cli-service serve",
    "test": "vue-cli-service serve --mode test",
    "prrod": "vue-cli-service serve --mode prod",
    "preprod": "vue-cli-service serve --mode preprod",
    "build": "vue-cli-service build",
    "build:dev": "npm i && npm run build",
    "build:test": "cross-env NODE_ENV=production vue-cli-service build --mode test",
    "build:preprod": "cross-env NODE_ENV=production vue-cli-service build --mode preprod",
    "build:gray": "npm i && npm run build",
    "build:prod": "cross-env NODE_ENV=production vue-cli-service build --mode prod",
    "analyz": "NODE_ENV=production npm_config_report=true npm run build",
    "lint": "vue-cli-service lint",
    "prod": "npm i && npm run build",
    "prod:uat": "npm i && npm run build",
    "prod:dev": "npm i && npm run build",
    "prod:preprod": "npm i && npm run build",
    "version": "conventional-changelog -p angular -i CHANGELOG.md -s -r 0"
  }

在根目录下，增加env文件，不同环境读取不同的文件

2.保留一种的登录方式

跟产品商议，登录方式只保留一份，不然每次需求迭代会增加测试的压力，只有部署到相应环境才能验收，设计不合理；

产品要求走统一的登录，去一个公共登录页登录，之后就跳转到后台首页。

这也就是导致令牌格式不同的原因，这样就改造成只保留一种令牌格式，还好接口都兼容这两种格式的令牌，所以后端不需要改动；

3.菜单接口改造

这需要后端配合，只返回菜单的路径，不需要连着域名返回，这应该也是之前开发设计不合理导致的，所以前端就设计成按域名来判断环境了。

改造后：

1.不需要修改host系统文件，可以直接localhost、127.0.0.1访问

2.环境根据环境变量区分，本地调试不同环境的接口，使用不同的启动命令即可

3.接口域名写在env文件中

4.保留旧的测试环境分支改名（为防止后面需要复现旧的测试环境功能），删除test分支，将master分支新建test分支

5.跟产品商议，登录方式尽量统一，最后跳转到IAM统一登录

6.菜单接口兼容，不写死域名，直接返回菜单目录

注意事项

1.改造不仅仅需要考虑当前的优化，也需要为以后开发提供便利；

2.在改造之前，需要保留之前的记录，防止后面想要找之前的代码找不着；

3.不要害怕改造，改造之后不仅仅为自己以后开发提供便利，也为以后维护更加快捷；

4.相信自己，只要自己认为是对的决定，就大胆跟leader提出来；