开发心得-心得+案例
2018-7-4 10:08:24 星期三
2022-2-22 更新
开发过程中会有些感悟, 在这里总结下来, 以便查看:
(注, 以下总结在应用时视场景不同需要做对应的变通)
软删除
在设计每张数据表的结构时, 加一个字段(比如: deleted) 来标记此条记录是否被删除, 而不是物理删除(sql: delete from where id=...)
好处有:
1. 便于查看和复盘业务场景变化
2. 安全, 与此同时, 所有用户(包括代码配置的用户)都没有数据删除权限
默认值
数据宁可留空, 也不要给一个可能出现或出错的值
比如, 一个字段记录了产地或结算对象, 入库的时候默认为0, 但是0不代表任何意义, 真正在业务上会被用到的是其他值
业务中如果遇到有0值的数据, 要么不处理, 要么报错.
(一些简单的状态值管理不适用此规则, 比如是否是删除状态, 只有0和1两个状态)
文案信息最好放数据库
比如, 邮件模板, 短信模板, 消息提醒模板等长文字信息, 这些内容可能会细微变动, 放到数据库中而不是代码中, 方便更改
(其实我觉得, 大部分的配置都可以放到数据库中, 除了数据库配置, 只是读的时候有些延迟, 但也可以解决, 可以代替类似 Nacos 这样的配置分发组件的大部分功能)
每添加一个字段:
1. 前后端针对此字段的校验是否要加上
2. 是否跟其他字段有关联, 是否需要联动
3. 前端的 添加/编辑/列表/详情/搜索/权限 页面是否要展示此字段
4. 手机端(app/h5) 相关页面是否也要展示
5. 后端对外提供的接口服务是否要加上
6. 调用此字段相关接口方是否要告知其改动
接口设计
1. 按照功能维度设计接口, 每个接口只负责单一的功能
2. 按照 增,删,查,改 分为四大类(或四个)接口, 具体操作哪个模块的数据, 通过传递参数的不同在后端进行分发处理
类的方法最好是静态的
1. 所有方法都是静态调用, 就不用每次都先new 再使用了
2. 避免了循环包含导致内存溢出
用一个类文件去定义所有的常量
有一个统一的地方管理, 方便维护和查看, 也能减少无谓的思考(只要是用到常量都从这个类中取, 只要增加常量, 都写在这一个类中, 不再纠结)
文件日志都加上traceID
稍大一些的系统, 即使不跨系统的调用, 也会有很多交叉日志, 如果没有跟踪号, 就很难查找
尽量避免依赖自增ID
比如要插入两条数据到两个表, 这两条数据的关联(left join on)字段最好使用唯一编码而不是用自增ID
这样的好处有:
1. 可以并行操作, 第二条数据的入库不依赖第一条的结果, 也不用等第一条结束 (关联用的唯一编码是事先生成好的)
2. 系统难免有bug或数据初始化, 有时需要手工写脚本生成SQL, 直接改数据库; 这样的话, 可以在不依赖线上数据库的情况下, 在线下把SQL生成好, 最后一次性执行
3. 系统难免会拆分或合并, 做数据迁移时, 也不用考虑自增ID的冲突问题
跟主干无关, 实时性要求不高的都做成异步的(合理利用事务)
例如:
1. 每注册一个用户, 成功后, 都要给他送一些优惠券.
这里主干是用户注册, 注册的步骤走完了就可以返回成功了, 送优惠券可以异步执行.
两者不必在一起加一个事务; 也就是说, 送券即使失败了, 也不应该告知用户注册失败
2. 添加一条业务数据, 这条数据需要指定一个负责人
这里的主干就是业务数据入库, 业务数据本身有一堆信息, 都是确定的, 但是负责人需要一堆的逻辑去找出来, 会有些耗时
负责人可以慢慢找, 找不到也不应该影响业务数据的入库, 以及后续的业务逻辑
最好设定一些准则 / 标准, 它规定了:你至少要做哪些事情 / 你最好怎样去做
如果没有一个标准, 就很可能会:
①每次都临时想方案
②遗忘常见但必做的事情
比如: 要求自己在设计功能的时候, 画一些用例图, 流程图, 状态图等
他们规定了我们至少考虑的几个方面:
1. 用户是谁,
2.用户在哪些入口使用
3.操作对象是谁
4.操作流程都有哪几步
5.成功后下一步做什么, 每一步失败(异常)后下一步做什么
有了这样一个"准则", 我们做方案设计的时候, 就少了些不确定性, 因为这些是必须考虑的
比如: 要先确定这个功能是谁在使用, 这就涉及到用户的角色, 和其所拥有的权限控制, 相关操作界面怎么显示等等, 这样你就不会遗漏对用户权限控制的功能开发
情景: 我最近做任务单分配的功能, 一开始沉浸在里边一直想, 这个类型任务单怎么分配给谁, 那个类型的任务单怎么分配给谁, 等想好了这些,
确被提醒说, 没有考虑人工干预分配的情况, 我这才回过头来从头考虑, 谁在使用这个功能, 在什么场景下使用这个功能:
使用代码自动分配 -> 部门内分配,
有权限的上级部门的同事 -> 跨部门分配 -> 分配给部门负责人 -> 再由代码分配
函数入参数的个数
1. 有人觉得语言本身又没有那么严格的限制, 我想怎样都可以
缺点是: 如果太多参数,
一是调用时必须按照参数顺序传输, 即使有些不用传也得传空,
二是参数越多逻辑就很有可能越复杂, 改都不敢改,
三是一些时候其实只需要其中一段逻辑但是仍然要走很多无用的判断, 甚至取出很多无用的值
2. 有人觉得最好只定义1个, 一个参数一个结果, 很纯粹的方法, 一看就知道需要啥
缺点是: 1个参数的话方法过于简单, 能处理的逻辑有限, 必须通过多个方法去实现一个目的
3. 我个人觉得最好不超过两个, 参数不多记着也方便, 大概也能猜出方法是干啥的, 可以控制稍微多一些的逻辑, 但也不会太多, 阅读也方便
类的构造方法参数个数
问题: 构造方法是一个类的入口, 比较特殊, 它要做一些初始化的操作, 因此很多构造方法要写很多参数
现实: 但是经常遇到的情况是, 之所以要写一个单独类, 很可能是为了把一些方法整合在一起:
1. 可能这些方法是处理同一个数据库表的, 这些方法被其他功能模块使用, 并不依赖构造方法的参数
2. 也可能是为了实现一个共同功能模块的方法的集合, 这时, 很多方法也并不依赖于构造方法的参数, 有些甚至不需要参数, 独立的可以单拎出去
构造方法的作用一般是 根据传递来的一个或几个参数, 再获取出一大堆相关的数据作为成员变量,
但不是每个方法都需要全部的成员变量, 如果都放在构造函数中去初始化, 难免会浪费资源
我的方案: 构造方法尽量不定义入参, 每个成员方法也有必要的参数, 以便让其他调用者知道该传什么参数
每天从1生成自增编码
接口测试和页面测试都要做
通常开发完接口, 我们自己会造一些数据, 去测试接口是否能跑通, 但不足之处在于:
1. 接口返回的数据是一大堆, 很容易漏掉重要数据的检查;
2. 测试接口的数据, 很可能是手工输入的, 接口虽然正确了, 但页面测试时, 可能缺少这些数据而报错, 比如:
显示列表页, 需要返回id, 但接口没返回, 然后, 详情页面, 需要ID时页面测试就会报错, 但接口测试, 因为是手工输入的ID, 就不会报错
