Skip to content

Latest commit

 

History

History
84 lines (79 loc) · 7.04 KB

后端开发流程.md

File metadata and controls

84 lines (79 loc) · 7.04 KB
Raw

后端开发流程

流程：API Document -> 新建分支进行开发 -> models.py -> views -> urls.py -> postman testing on localhost -> git commit & sync -> postman testing on cloud server这一步可以省略，一般在本地通过测试以后，服务器上应该也不会出现问题 -> 通过测试后将新功能分支合并到master -> 上线部署 -> API Document

  1. 明确产品需求
    1. 知道产品的作用、功能
    2. 可行性分析
    3. 选择技术栈，优先选择大家都会用的：Django+MySQL
    4. 关键模块设计方案：
      1. 用户登录模块，调用TB用户系统接口
      2. 数据库
        1. 数据库设计
        2. MySQL建表时，拆表，允许冗余信息（加快查询速度）
        3. Redis
  2. 前后端对接，设计API文档
  3. 开发
    1. 日志模块
      1. settings.py中定义LOGGING
      2. views中启用logger:logger = logging.getLogger('django')
      3. 当程序raise error （日志等级为ERROR）时，日志会记录下错误信息（根据settings.py中的配置）
      4. 给管理员发邮件通知错误信息，需配置ADMINS以及一些邮件参数
      5. 详见：https://note.qidong.name/2018/11/django-logging/
    2. 后台管理模块
      1. Django admin
    3. Django项目规范
    • models.py数据库设计
      • 一般情况不需要更改，更改过多时迁移migrate会遇到错误，遇到错误的解决方法见Database。
    • /views/xxx.pyAPI实现:
      • 大部分的工作会在这里完成。最好是先在API文档中定义好request和response。
      • 查django官方文档或者google解决，也可参考之前的代码，POST和GET两种接口的写法几乎是固定的。
    • urls.py后端路由:
      • 将/views/xxx.py里面的函数映射到某个url上，一般在完成views后修改。
      • 小心两个url发生冲突。例如：api/handbook/<str:category>/<int:order>/与api/handbook/category/<str:category>/会发生冲突
    • 注意API文档要与views，urls.py同步更新。
    • 需要保密的信息写在local_settings.py中，其余写在settings.py中。如数据库配置、邮箱账号密码、SECRET_KEY需要保密。
    • views.py拆分成多个文件
      • views文件夹相当于一个python包，在urls.py中，通过from qa.views import *来导入。在指定某个方法时，需要加上该方法所在的.py文件的名字，如原先的get_user_info需要改为user.get_user_info。
      • /views/__init__.py中__all__ = ["core", "user", "qa", "handbook", "search", "others"]指定允许被导入的包。
      • views/下按照具体业务or数据库模型归类，如views/user.py是所有关于与user用户相关的接口，views/qa.py是所有与问答相关的接口。这样会使代码逻辑更清晰，更容易维护。
    1. 用户反馈模块
  4. 测试
    1. 在未使用单元测试前：
      1. postman进行接口测试，自己想边界情况，保证接口正常运作
      2. 测试数据库与生产数据库分离，如activity_test是测试数据库，activity是生产数据库
    2. 压力测试
      1. GoReplay https://github.com/buger/goreplay
    3. 单元测试
  5. 部署
    1. 服务器
      1. 连接服务器
        1. ssh
        2. VsCode Remote-SSH
      2. $ python manage.py runserver <port> 可以开一个终端窗口一直运行这条命令，每次更改代码后django都会自动重启，无需每次手动重启django。
      3. 服务器上使用screen命令来保存终端信息：查看运行中的窗口screen -ls, 切换到窗口screen -x <id>（不会将他人踢下线）
      4. 安装python包：可以一个个安装，也可以在开发服务器上用pip freeze > requirements.txt，然后将里面的内容复制到生产服务器上，用pip install -r requirements.txt来批量安装。
      5. 查看local_settings.py，更改数据库设置（如果需要），ALLOW_HOSTS应该也要改下域名。
      6. 数据库迁移：python manage.py makemigrations <app_name> python manage.py migrate
        1. 迁移前视情况对数据库进行清空，请事先备份。
      7. python manage.py collectstatic 生成静态文件。
      8. 更改Nginx配置文件nginx.conf，设置静态文件路径。
    2. Django 部署清单:
      1. https://docs.djangoproject.com/zh-hans/3.1/howto/deployment/checklist/
      2. python manage.py check --deploy
    3. 自动部署：GitHub Actions

git使用

  • 分支管理：每次需要加入/修改某个功能时，从master新建一个分支，名字就是该待办事项的名称，完成后将其合并到master中并删除该分支。如：前端传给后端的label字段是列表，需要转成字符串再保存到数据库这个需求，就可以建立一个分支叫label列表转字符串，切换到该分支并完成开发后，将其合并到master中，经测试后无问题即可删除该分支。
  • commit信息要写完整，写详细，解决了某某需求，修复了某某bug，中英文皆可（可中英文结合），如：API: 修改get_suggested_questions接口，按照问题下的回答的点赞总数从大到小排序。
  • 单次commit内容尽量不要太少，最好是实现了一个需求，或是解决了一个bug。
  • 除了紧急修复运行中的bug，其他情况不要直接在服务器上面改代码，后端容易崩。
  • Tag用于标记版本，如v1.0是第一个发布的稳定版本，v1.1增加了某某特性

Database

  • ⚠尽量不要直接操作数据库，而是通过已经写好的API来操作。
  • tips：下载MySQL Workbench来可视化管理数据库，进行敏感操作（更改/删除）时要小心。
  • local_settings.py中设置数据库
  • python manage.py makemigrations <app_name>
  • python manage.py migrate <app_name>
  • migrate迁移过程中发生错误怎么办？
    • 首先查看错误信息，常见的有：将某个字段改为unique时，由于该字段已经存在重复的数据，不满足unique constraint，数据库会报错。
    • 有些错误可以通过django的引导来更改，比如提供一个default值。
    • 而像上面所提到的错误则需要手动更改重复的数据，使该列满足unique constraint。
    • 有时候migrate进行了一部分，剩下另一部分由于出错而没有进行，或已经直接对数据库进行了相应更改。此时可以找到对应的迁移文件/migrations/xxxx_auto_yyyy.py，手动将已经迁移的部分删除，再进行migrate。为了避免下次migrate因migrate不完整而出错，我的解决方法是：migrate全部完成后，将对应的迁移文件/migrations/xxxx_auto_yyyy.py删除，再python manage.py makemigrations qa重新生成完整的迁移文件，然后通过该命令跳过该迁移python manage.py migrate <app_name> xxxx --fake（xxxx是当次迁移文件的编号）