做了一个农大科技市场的一个商业项目,印象深刻的是关于协同办公里的物品申领,它的流程图如下:
就是普通员工申领物品由部门经理来审核,部门经理申领物品直接由总经理来审核,审核不通过需要填写驳回理由。
当时写后台考虑不周到,导致多封装了个方法,因为部门经理审核直接由总经理来审核,所以前端没必要再传总经理的信息,但是把查询总经理和部门经理封装为了一个方法,其实是没必要的。
写代码要考虑周全
在写的时候一定要注意是一对多关系还是多对多关系,传回来的信息是单个实体还是一个集合。
还有就是写的时候用的是rbac权限模型,我有一块没考虑到角色和用户,在部门经理添加申请时,我后台业务自动添加绑定的总经理时直接写死是哪个用户,导致总经理角色没改变,但用户id由2更改为3后添加的申请没绑定到总经理的用户上,而是写死了,这就导致了添加的总经理用户不存在,所以以后要注意角色和用户的一个关系,不能认为这个角色会一直是某个角色。
数据库表字段冗余问题
有个组员写的出入库管理,在出入库表里写了几个冗余字段,而我总会想着前端要把所有信息会传到后端,所以我就指导错误,其实后端是不能完全相信前端传来的信息的,尤其是冗余字段,它只是为了好查询,向冗余字段里插入相关信息还得是由后端查询相关数据库表来插入信息的
业务要了解客户需求,不多写,也不少写,避免镀金,也不要少写。
在写完的项目需要不断的迭代来完善。
前端的回调函数和lamda表达式已经忘了,需要再复习一下。
单表的增删改查已经没问题。多表需要根据具体业务来考虑写法。
尽量写出的方法可以复用,代码尽可能细化,没必要所有业务逻辑都写一个方法里。
分层让代码逻辑更易于别人理解,注意要好写注释。