实习日记Day23——业务小白理解业务瑟瑟发抖

来这边也20多天了，再过几天15号发工资，迫不及待，口水直流。这周还是写接口，但是接触到一些稍微复杂的业务场景了，对项目的架构和一些工具类也比较熟悉了。我写完接口就会去看那些利用率比较高的工具类接口或者框架接口，去看下底层是怎么实现的。不看下到底是怎么写的，我用的总是不踏实，也不太敢用。

比如项目传入了一个pageRequest,在xml文件上面没有看到相关的分页代码，但是就是分页了，我就一直查一直追，后面才看到是配置了一个分页插件，基本逻辑也比较简单，就是判断是不是pageRequest对象，是的话拼接sql语句，不是的话就执行原来的流程。

还有就是，之前在网上也查了一些数据库主键的生成策略，主要就是UUID，雪花算法，数据库自增ID，redis这一些。我们公司的项目中也用到了主键生成策略，不过用的是数据库的序列号生成器来生成，再加上时间戳。不过公司的数据量有点小，应该也用不上什么分库分表或者是分布式数据库来拓展。（这个可能之后得恶补一下）

这周写接口，遇到了一个接口幂等性的问题（应该是吧），因为带我的哥一直想让我把代码写的简洁一些，所以我就尽量简洁，看前人写的一些代码，在健壮性校验那一块其实聊胜于无，我就在纠结我要不要写健壮性校验，心里两个小人一直在嘀咕，写了的话代码就会冗杂，其他层也得增加代码，况且我们这个项目只是面向某些组织内部，不会完全对外开放，有前端做校验是不是就可以了。但是后面还是写了，还是坚持自己一直以来的想法，任何前端的校验对后端来说都不可靠，都是可以绕过的。写了之后才发现，如果不做这个校验，短时间内点击这个接口多次，会导致数据库插入ID不同但是其他数据完全相同的数据，这样就会影响到业务的正常运行。（所以某些幂等性的问题也可以用业务逻辑来避免）

之后就是觉得还好我做了校验，因为我mentor对我代码审查也不是很严，我就更得把好自己的代码质量。自己在测试自己的接口的时候，也要多搞一些边界条件去测，正常不正常的都得去测，才能发现问题，不要测试一下，看到数据成功改变了就算成功，这也是对我自己的一个提醒。

对于我来说，其实增删改查的接口在学校已经写的很多了，其实也就一些工具类的使用或者某些框架使用上的不同。难的还是怎么去理解这个业务场景，组内的哥给我讲业务我还是需要时间反应的，一时间会懵一下，不过循序渐进吧，只要有成长，就有意义。