【私活日记】—— 帮朋友处理个小BUG,震惊了(ΩДΩ)

大家好 ,这里是8老月,今天跟大家分享一下,去年帮朋友公司【也是一个小的接项目外包的公司】修一个项目bug的事情。

事情是这样的,去年朋友公司接了个小项目,然后因为公司人手不够就把这个项目外包给一个个人开发者去做了,前面做的还好,后面因为那个人他自己公司很忙了,也就没再继续搞了,朋友就让我帮忙修复一下剩下的bug,我当时也不是特别忙就帮他看看,这一看不得了,这兄弟的写法属实把我吓到了。

这里先介绍下里面的用的框架,普通的springboot框架+mybatisplus2.x。

一、吐槽点

1.mapper层返回对象全是map/list<map>

那我们都知道mybatis是允许使用map对象进行返回的,LIst<Map>或者返回一个纯粹的map对象,但是这兄弟的代码,自己的mapper类返回对象全是map、list<map>,这里我截图了2个地方。

不是说不能用这种返回方式,而是大量使用这种返回方式会导致维护困难,代码无法阅读。

2、接口需要分页返回的地方全部是一次性返回全部数据,分页在前端分页,不是一个两个接口,是所有,这就导致了本地连接服务器数据库进行开发测试的时候,接口响应非常慢,而且这种做法是非常不合理的,也亏得生产上应用和数据库服务器是在局域网。

3、字典数据未缓存,且每次需要字典数据的时候都是单独查询,举例说明下,例如接口是查询用户信息,用户结构(用户id,姓名,性别【字典值】),在第二条的基础上,一次性查询出所有的用户信息,依次循环处理性别字典值,100条数据的话,循环查询性别字典100次,可想而知这样的接口的效率是怎么样的。

 

二、引申思考

1.mybatis的mapper层尽量使用明确对象进行返回,map返回不是不能用,但是非常不推荐。

2.该分页就得分页,除非是小型数据,比如字典值一类的,确认不会很多的数据的情况。

3.如果遇到上面第三点的情况,需要联合字典数据进行展示,首先字典数据应当在前端有缓存,在前端进行字典值数据展示,后端只需要处理字典编码。如果后端代码确实需要对字典值进行操作,那么后端应当缓存字典值,且应当批量操作,而不是循环每个数据。如果字典和业务数据表没有分库,在sql连接表数量不多的情况下也可以直接连接字典表进行字典值展示。

4.不管是工作或者自己写一些小应用的时候都应当注意接口效率和代码阅读性,大部分的时候去阅读自己写的代码的人都是自己。

 

  • 0
    点赞
  • 0
    收藏
  • 打赏
    打赏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
©️2022 CSDN 皮肤主题:游动-白 设计师:我叫白小胖 返回首页
评论 1

打赏作者

8老月

你的鼓励将是我创作的最大动力

¥2 ¥4 ¥6 ¥10 ¥20
输入1-500的整数
余额支付 (余额:-- )
扫码支付
扫码支付:¥2
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值