标签：返回 map 代码 接口 日记 私活 数据 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.不管是工作或者自己写一些小应用的时候都应当注意接口效率和代码阅读性，大部分的时候去阅读自己写的代码的人都是自己。

标签：返回,map,代码,接口,日记,私活,数据,BUG,字典
来源： https://blog.csdn.net/m0_51211957/article/details/116306461

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。