答应我,不要再用 Map 做出入参了好吗


本文摘自网事全知道,侵删。

1. 前言

今天聊聊我们接触最多的接口,主要是聊接口上的出入参,有的同学就说了,啊不就是接口入参吗,有什么好聊的,大家不都这样用吗,都成规范了;但是所写,都是我在实习公司听到的、见到的一些”现实“

其实聊这个问题,就是希望一些新入行的同学也好,还是外包行业的一些”老油子“也好,我们不得不承认,有些时候我们正在生产难以维护的代码。

虽然这个难以维护是相对的,假如这个项目写出来后,就不再需要任何的维护,不会再有任何的改动,那理论上随你怎么写,因为不会有人再去看这段代码;但是现实中真的有这种情况吗,哪怕有,我相信也很少

2. 使用 Map 作为入参的现象

当我入职的时候,第一个任务是熟悉项目,在我一顿操作后,打开代码,发现接口层出现大量的这种代码:

@PostMapping("/addProject") public Map addProject(Map map) { //对某个参数进行校验 if (map.get("id") == null) { throw new Exception(); } //使用faster json将map转为对象 Project project = ObjectUtil.ConvertMapToBean(map); //经过service处理后再返回Map给前端 Map result = projectService.add(project); return result; } 复制代码

别的不说先,这里首先就有几个很明显的问题:

  1. 难以维护:接口入参使用了 Map 进行封装,如果没有接口文档,维护的人很难知道到底传的是什么参数进来,直接进行调试也变成了不可能
  2. 参数校验又长又臭:需要手动对进行参数校验,假如需要校验的参数特别多,那这个参数校验是不是要写特别的长?
  3. 低效:每一次入参都是用了 FasterJson 进行转换,这样大大降低了接口的效率,特别是 QPS 高的时候
  4. 空指针异常:容易造成空指针异常,当我们代码中需要用到的参数去 Map 里获取,假如参数校验没做好,且入参的时候没有传,就会出现空指针异常

当我带着这些问题找到项目的负责人,一开始我认为会是一场讨论,然而我得到的回复是:”这样开发是有好处的,这大大减轻了后端开发的难度,让我们用更少的代码,更少的时间可以把这个事情做好!“

所谓道不同不相为谋,既然项目负责人坚持这么用,那就可以说得通为什么代码里面到处都是这种风格,甚至为了解决使用 Map 而出现的问题封装了一堆解决这些问题的工具类。

带着这些问题我又继续深入学习,一段时间后,我果然的发现,他们是没有接口文档的,不是他们不想用 Swagger,是因为 Map 的封装导致 Swagger 根本无法使用,并且出 Bug 的概率也是相当的高

阅读剩余部分

相关阅读 >>

iphone se 3跌落测试:比前代更耐摔了 与iphone 13表现相当

以色列将建立独立自主的量子计算能力:开发本国首台量子计算机

索尼微软两巨头接连表态:将重新评估与动视暴雪之间的合作关系

intel正式发布12代酷睿移动版:5ghz

智享生物获超5亿元c轮融资,高榕资本和清松资本

抖音与腾讯视频达成合作,可开展短视频二创

人类将成为真正的“上帝”?科学家用量子计算机,创造了量子生命

《多元宇宙大乱斗》玩家数超两千万 华纳总裁:开门

快手再传裁员:覆盖四大事业部,个别团队裁员比例30%

开放大世界手游or端游曝光,《逆水寒》开放大世界玩法

更多相关阅读请进入《新闻资讯》频道 >>



打赏

取消

感谢您的支持,我会继续努力的!

扫码支持
扫码打赏,您说多少就多少

打开支付宝扫一扫,即可进行扫码打赏哦

分享从这里开始,精彩与您同在

评论

管理员已关闭评论功能...

    暂无评论...