对公司产品的重构想法
Smoothness
# 对公司产品的重构想法
最近算是完整的参与了人生中的第一个大型项目：一个监控行业的产品，界面上大概有15个大模块。
产品本来就算是一个半重构的项目，以前是c++、python混杂着写的，现在web基本都改成了python
本来是准备采用flask写，但是当时领导坚持要使用C++调用python的方案，但是C++的web不支持
WSGI或ASGI协议，最后自己手搓了一个Mxsoftpy框架。
# 项目代码结构
- 现在的代码结构问题
之前没有做过这种大型项目，建立项目的时候还是按照以前的想法建的
pyweb
db
model
server
utils
view
1
2
3
4
5
6
2
3
4
5
6
然后view、server、model、db分别建立了各个模块的文件夹 如果开发人员少这个目录还可以，互相调用也还算清晰。 但是开发人员多，而且还出现同一模块换人写，写代码和改bug的人不同的现象。 然后数据权限也调整了好几次，还需要兼容两个平台的不同权限融合（我们作为一个模块融合到别人公司的平台）， 产品代码已经出现混乱的迹象了。
- 新的代码结构
pyweb
xxx(各模块文件夹)
interface 提供给内部的功能接口，入参和出参都严格使用model
db 严格限制对每个实体至少拥有一套curd方法，按照实体区分类
model
entity 实体模型
in 请求参数模型
out 返回数据模型
interface 接口模型（in、out）
server
view 注释中添加接口文档
utils
1
2
3
4
5
6
7
8
9
10
11
12
2
3
4
5
6
7
8
9
10
11
12
# 权限封装
现在的权限入口过多，设备、用户两边都提供了很多权限接口，除用户模块外，其他模块应该只需要数据权限
# 接口
开发的时候太赶，模块之间的方法复用基本没有，db和model各自写各自的
优化原则：
- db层统一复用，各模块实体的增删改方法只写一次
- view的接口数据需要数据校验（请求数据严格序列化、响应数据推荐序列化）
- 需要跨模块调用的逻辑在interface中写一份
- 禁止一个url写多个逻辑，前端在不同模块调用类似功能的url时，写成多个，不要凑活改
- interface层的方法注释写完整（方法使用、参数模型类、返回数据模型类）
# 数据存储、模块间数据联动
- todo 业务数据增删除（特别是实体）会影响到多个模块，详细排查这些隐患
- 严格的统一数据库字段命名风格，实体统一使用is_del，关系统一直接删除
- 当前数据库存储结构正常，无需改动
# 异步支持
接口已经支持async，重构时可以改为异步
# 日志
尽管我已经多次强调日志，仍有info和debug不分，日志信息记录不详细等情况，甚至有些人员调试只依靠Mxsoftpy的全局异常捕获， 记录时需要认真思考（自己根据此条日志能否排查问题）