其实最近看代码,发现好多地方实体以及数据库DDL语句关于空值和默认值不是很统一,有时候排查问题会让你很日了狗,在最佳实践和标准的选择上,归根接地是一场小的生产力的革命,只有生产力的革命才能真正的达到降本增效。
这也是阿里 Java 代码规范,VO,DTO,DO等传递的时候都不要默认值,默认值一时爽,如果你给下游返回一个空对象,如果有默认值你让下游怎么判断空?不要为了自己插入数据一时爽,可以借助于Mapstruct去定义一个converter方法,也可以自己去定义一个init方法去初始一些值。
至于基础类型和包装类型有什么区别这里不说了。如果使用基础类型,byte和boolean等,实例化的对象也是不为空的,这给下游判断增加很大负担。
不建议使用包装类型,service里面局部变量一定是可以具体到基础类型的。可以省去一些包装类型比较的坑以及一些不必要的NPE。
ORM框架里面使用包装类型
这样的话,在Mapper.xml 里面,拼SQL语句的时候判断某个字段!=null 即可,不需要多余的判断。
数据库尽量也不要给default以及null
建表的时候约束条件主要有primary key、unique、not null、default等。not null是非空的约束,也就是不能向表里插入空值。default是在不给字段输入值时,比如空值,是不会触发default的。除String类型外字段外,金额(BigDecimal),RID(Int)等,都不应该设置为可为NULL,NULL的话不利于数据库查询优化。not null 和 default是两个独立的约束,可以用在一个字段上。
其实当你发现这些问题的时候,你也想改的。问题在于,当你关注这些细节多的时候,你就会忘记自己要干什么。什么增量迭代,绞杀者模式,都抛到了脑后。
前两个看到关于重构系统的十六字心法,非常形象和贴切。旧的不变,新的创建。一步切换,旧的再见。
“旧的不变”是指先不动旧方法;“新的创建”是指创建一个跟原来方法功能相同的新方法,你可以通过先复制再重构的方式,来得到这个新方法,也就是整个系统的一个增量;“一步切换”是指,在充分测试之后,新的方法可以完全替代旧方法了,就将开关切换到新方法上;“旧的再见”则意味着删除旧方法以及相应的开关,一个演进到此也就结束了。
而增量演进原则可以有效解决这个问题。它一方面鼓励我们持续交付改造的功能或新的实现,不断在生产环境验证;另一方面拥有细粒度的开关,也使得回退变得十分灵活,一旦发现问题,我们只需要关闭引起问题的那个开关即可。
重构的目的,也是为了业务赋能,脱离业务的技术改进都是耍流氓,这样的技术任务是很难验收的,而且上线之后,业务方无法很容易地感知它所带来的价值。比如说Bug数减少,工单数减少,这样的话业务才会支持我们下一步计划。