本文摘自网事全知道,侵删。
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; } 复制代码
别的不说先,这里首先就有几个很明显的问题:
- 难以维护:接口入参使用了 Map 进行封装,如果没有接口文档,维护的人很难知道到底传的是什么参数进来,直接进行调试也变成了不可能
- 参数校验又长又臭:需要手动对进行参数校验,假如需要校验的参数特别多,那这个参数校验是不是要写特别的长?
- 低效:每一次入参都是用了 FasterJson 进行转换,这样大大降低了接口的效率,特别是 QPS 高的时候
- 空指针异常:容易造成空指针异常,当我们代码中需要用到的参数去 Map 里获取,假如参数校验没做好,且入参的时候没有传,就会出现空指针异常
当我带着这些问题找到项目的负责人,一开始我认为会是一场讨论,然而我得到的回复是:”这样开发是有好处的,这大大减轻了后端开发的难度,让我们用更少的代码,更少的时间可以把这个事情做好!“
所谓道不同不相为谋,既然项目负责人坚持这么用,那就可以说得通为什么代码里面到处都是这种风格,甚至为了解决使用 Map 而出现的问题封装了一堆解决这些问题的工具类。
带着这些问题我又继续深入学习,一段时间后,我果然的发现,他们是没有接口文档的,不是他们不想用 Swagger,是因为 Map 的封装导致 Swagger 根本无法使用,并且出 Bug 的概率也是相当的高
相关阅读 >>
iphone se 3跌落测试:比前代更耐摔了 与iphone 13表现相当
人类将成为真正的“上帝”?科学家用量子计算机,创造了量子生命
更多相关阅读请进入《新闻资讯》频道 >>