规范

Subepy
171 阅读4分钟

前端

1.接口

  • 现状
proxy: {
          '/dev-api': {
            target: 'http://127.0.0.1:12012/',// 后端接口地址
            changeOrigin: true,
            rewrite: (p) => p.replace(/^\/dev-api/, '')
          },
          '/zuma': {
            target: 'http://127.0.0.1:12012',// 笔记
            changeOrigin: true,
          },
          '/files': {
            target: 'http://127.0.0.1:12012',// 笔记
            changeOrigin: true,
          },
          '/upload': {
            target: 'http://127.0.0.1:12012',// 笔记
            changeOrigin: true,
          },
          '/prod-api': {
            target: VUE_APP_API_BASE_URL,
            changeOrigin: true,
            rewrite: (p) => p.replace(/^\/prod-api/, '')
          }
        }

  • 引发的问题 无论是前端开发者还是全栈开发者，在调用接口的时候都有很大的可能没有看过vite的配置，而导致API明明和后端一样，本地也没有问题，在线上却无法访问

  • 规范 一般前后端分离， proxy只配置一个，通常为

proxy: {
  '/api': {
    target: 'http://127.0.0.1:12012/',// 后端接口地址
    changeOrigin: true,
    rewrite: (p) => p.replace(/^\/api/, '')
  },
}

一般仅此一个，API以/api开头若有版本，后可接版本，例如'/api/v1/'

  • 栗子 以本次公式上线为例，开发者说本地测了没问题，结果调线上API返回404，看了前端代码发现，他的API为'/formula/list', 后端同样如此，这没问题，但是nginx没有配置/formula这个uri应该指向哪里，当然也不应该配置，一般nginx只需要配置一个根，再加一个/api，再加一个静态文件的路由即可，公式上线暴露出前后端开发者可能对nginx不了解，也不知道我们做了什么配置，导致上线周期长。 由此，我们应统一proxy只有一个或者两个，nginx只配置根和/api和静态文件，行业普遍如此，开发者也不必了解nginx以及我们如何配置的nginx；BASE_URL也可以起到它应有的作用。

2.代码风格

  • 计划
  • VUE3 composition API 添加pre-commit，强制校验代码（较复杂，暂不做）

后端

1.接口

2.依赖

  • 现状 使用requirements.txt作为依赖记录
  • 缺点 依赖不清晰，且不会自动更新依赖
  • 栗子 以我首次开发zuma为例，只是安装后端的依赖就花了一晚上，因为requirements.txt记录不全切版本冲突，询问三川和后期在群里看别人聊天也提到过同样的问题
  • 解决 使用poetry作为后端包管理工具，添加依赖时会自动生成记录并更新依赖文件，极大降低开发者首次开发zuma后端所浪费的不必要时间，同时系统依赖清晰，版本明了

3.代码风格

  • 计划 添加pre-commit，强制校验代码（较复杂，暂不做）

部署

1.后端

  • 现状 Django直接启动
  • 解决 起码不要像现在这样，直接用Django启动，性能太低，不符合生产环境，推荐使用gunicorn搭配nginx
  • gunicorn+nginx已实现
  • 后续
  • 使用docker部署，可无缝从windows服务器切换至任何服务器，包括本地，只是优点之一，优点太多了

2.自动部署

gogs可能无法实现，暂不考虑

  • gitlab CI/CD实现前后端代码质量检查及自动部署

开发

GIT分支

1.区分开发分支和上线分支，开发分支使用develop，测试环境同样适用develop，正式环境使用release，原则上不在release分支更新任何代码

2.给每个需求编号，且不重复，比如文档转化需求编号为ZUMA-1213，接到这个需求的开发者，首次开发应拉取develop分支代码，然后在develop分支的基础上建ZUMA-1213分支，进行需求开发，并不定期将develop代码合并到当前开发的分支，避免长时间开发冲突太多，待开发结束，提PR由我或MIKE进行review，然后merge到develop分支，这样可确保不同开发者之间隔离，且develop相对稳定，即使开发时出现bug不影响其他开发者开发！！！

3.开发周期结束测试没有问题，即可将develop分支merge到release分支，在生产环境使用

4.需求提出者不要关心开发者怎么实现，例如自动用户相关的业务生成表，这违背了ORM的初衷，这种需求很简单就能实现并不需要生成新表，待开发者做完后或者做前，问一下他的思路即可

avatar
文章
阅读
粉丝