来这边也20多天了,再过几天15号发工资,迫不及待,口水直流。这周还是写接口,但是接触到一些稍微复杂的业务场景了,对项目的架构和一些工具类也比较熟悉了。我写完接口就会去看那些利用率比较高的工具类接口或者框架接口,去看下底层是怎么实现的。不看下到底是怎么写的,我用的总是不踏实,也不太敢用。
比如项目传入了一个pageRequest,在xml文件上面没有看到相关的分页代码,但是就是分页了,我就一直查一直追,后面才看到是配置了一个分页插件,基本逻辑也比较简单,就是判断是不是pageRequest对象,是的话拼接sql语句,不是的话就执行原来的流程。
还有就是,之前在网上也查了一些数据库主键的生成策略,主要就是UUID,雪花算法,数据库自增ID,redis这一些。我们公司的项目中也用到了主键生成策略,不过用的是数据库的序列号生成器来生成,再加上时间戳。不过公司的数据量有点小,应该也用不上什么分库分表或者是分布式数据库来拓展。(这个可能之后得恶补一下)
这周写接口,遇到了一个接口幂等性的问题(应该是吧),因为带我的哥一直想让我把代码写的简洁一些,所以我就尽量简洁,看前人写的一些代码,在健壮性校验那一块其实聊胜于无,我就在纠结我要不要写健壮性校验,心里两个小人一直在嘀咕,写了的话代码就会冗杂,其他层也得增加代码,况且我们这个项目只是面向某些组织内部,不会完全对外开放,有前端做校验是不是就可以了。但是后面还是写了,还是坚持自己一直以来的想法,任何前端的校验对后端来说都不可靠,都是可以绕过的。写了之后才发现,如果不做这个校验,短时间内点击这个接口多次,会导致数据库插入ID不同但是其他数据完全相同的数据,这样就会影响到业务的正常运行。(所以某些幂等性的问题也可以用业务逻辑来避免)
之后就是觉得还好我做了校验,因为我mentor对我代码审查也不是很严,我就更得把好自己的代码质量。自己在测试自己的接口的时候,也要多搞一些边界条件去测,正常不正常的都得去测,才能发现问题,不要测试一下,看到数据成功改变了就算成功,这也是对我自己的一个提醒。
对于我来说,其实增删改查的接口在学校已经写的很多了,其实也就一些工具类的使用或者某些框架使用上的不同。难的还是怎么去理解这个业务场景,组内的哥给我讲业务我还是需要时间反应的,一时间会懵一下,不过循序渐进吧,只要有成长,就有意义。