1. 前言

今天，我们来谈谈我们接触最多的界面。 主要谈界面上的出入参与。 有个同学说，啊，不是参加界面吗，有什么好故事，大家不是都这样用吗？ 一切都已成为规范。 但是，写的是我在实习公司听到和看到的“现实”

其实说起这个问题，我不得不承认，无论是新员工还是外包行业的“老手”都在编写难以维护的代码。

这个很难维护是相对的，但是如果这个项目写出来之后，不需要任何维护，没有任何改变的话，理论上你怎么写都可以。 因为没有人去看这个代码。 但是，现实中真的有那样的事吗？ 即使有，我也觉得很少

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

我进公司的时候，第一个任务是熟悉项目。 我抽了一口气后，打开代码，界面层出现了大量的这段代码：

@后映射(/添加项目) )。

公共地图项目(地图地图)

//检查某个参数

if (地图获取(id ) )==空值) {

反向执行(；

}

使用faster json以地图为对象

项目项目=对象工具.转换映射(映射；

//进行服务处理后，返回Map交给前端

mapresult=项目服务. add (项目；

返回结果；

}

代码拷贝暂且不谈，这里首先有几个明显的问题：

难以维护：接口条目是使用Map封装的。 如果没有接口文档，维护的人很难知道进来了什么参数，直接调试也不可能进行参数检查，又长又臭。 需要手动配对进行参数检查。 应该检查的参数特别多的情况下，那个参数检查必须要用特别的长度写吗？ 效率低下：每次参与时都使用FasterJson进行转换，从而大大降低了接口的效率。 特别是在QPS高的情况下，容易发生空指针的异常。 容易引起空指针的异常，代码中使用的参数会在Map中获取。 如果参数检查不成功，并且在加入时未传递，则会出现空指针异常。 带着这些问题寻找项目的负责人。 我认为最初会成为讨论，“这样开发是有益的。 这样可以大大降低后端开发的难度，用更少的代码在更少的时间内完成此事。 「

之所以道路不同，是因为项目负责人既然坚持这样的使用方法，为什么代码中充满了这样的风格，以及为了解决由于使用Map而出现的问题，打包了很多用于解决这些问题的工具类呢

抱着这些问题，我又继续深入学习了。 过了一会儿，我还是发现他们没有接口文档。 不是他们不想使用Swagger，而是因为Map的软件包，Swagger完全不能使用，出现bug的概率也相当高

3. 为何还有人坚持这么做

据我理解，有三种可能性：

项目负责人追求的不是质量，特别是外包工作，而是迅速完成工作，乙方会完成合同并将代码交给你。 关于维护性等，谁有理由？ 开发项目的同事在初学时遇到了第一种情况的导师。 我以为这种情况是理所当然的。 由于多年的积累，既不想修改也不想修改。 于是又成了第一个人“老油子”，你们怎么用，我怎么用，怎么改变，什么的，不存在。 球队风格以我的风格

4. 现在我们怎么做

看完了反面教师。 现在，让我们来看看大部分人吧

@ post映射(/students ) )。

publicresponsestudentinsert (@ requestbody @ validatedstudentstudent ) {

返回成功(studentservice.save ) student )；

{现在的商业界面，可能这么容易理解。 看看这里包含了什么信息。

遵循Post风格的API，使用Post进行保存操作时封装了相同的ResponseStudent，返回的格式是统一的。 为了能够封装前端统一的接收格式，使用@RequsetBody实体系统对象接收Json格式的参数，一目了然，然后说明其优点。

参数检查：在接口条目中添加了@Validated注释。 可以通过添加与Student类相对应的参数检查注释来自动检查条目。 不合适的参数直接返回错误信息一目了然。 什么进去了，什么出去了，维护者一看就知道目的。 熟悉rest风格的人基本上都会知道你这个接口要做什么样的接口文档。 同样，该接口可以引入Swagger等自动化接口文档工具，在开发时可以花一点时间编写接口文档。 另外，更新时这少量代码

5. 写在最后

也可能随着技术、项目的迭代，这种现象越来越少。 但是，我想表达的是以下几点。

我们遇到技术时，不要盲目使用，要横向比较。 你必须明白他能做什么，不能做什么。 给未来的自己留条后路，你可能不得已做错了，但你要明白你做的是错的，努力改正那个错误。 例如，做好注释，用技术武装自己，即使你在这个行业呆一会儿，也要有基本的职业道德，尽量不要给后代埋坑