本文摘自网事全知道，侵删。
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 的概率也是相当的高
相关阅读 >>
苹果发布 ios 15.7.4/ipados 15.7.4 rc 预览版
meta高管解读财报：预计2023年资本支出主要来自对ai投资
更多相关阅读请进入《新闻资讯》频道 >>
