实在聊这个问题，便是希望一些新入行的同学也好，还是外包行业的一些”老油子“也好，我们不得不承认，有些时候我们正在生产难以掩护的代码。
虽然这个难以掩护是相对的，如果这个项目写出来后，就不再须要任何的掩护，不会再有任何的改动，那理论上随你怎么写，由于不会有人再去看这段代码；但是现实中真的有这种情形吗，哪怕有，我相信也很少
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 的概率也是相称的高
3. 为何还有人坚持这么做在我的理解来看，有三种可能：
项目卖力人追求快速的完成事情，而不追求质量，特殊是外包性子的事情，乙方只管完成条约把代码给你，至于掩护性什么的，谁理呢？开拓项目的同事在初学时，碰着了第一种情形的导师，认为这种情形是天经地义的，长年累积，不愿意改，也不想改，于是又变成了第一种人”老油子“，你们怎么用，我就怎么用，改变什么的，不存在的，团队的风格便是我的风格4. 现在我们怎么做看完了反面教材，我们来看看现在大部分人怎么做：
@PostMapping("/students")public Response<Student> insert(@RequestBody @Validated Student student) { return success(studentService.save(student));}
现在的一个业务接口，可能便是这么大略明了，让我们来看看这里都包含了什么信息：
屈服 RestFul 风格的 API，利用 Post 来进行保存操作封装了同一的返回工具 Response<Student>，返回的格式是统一的，让前端可以封装统一的吸收格式利用了 @RequsetBody + 实体类工具来吸收 Json 格式的参数，传了什么一览无余再来说说这样做的好处：
参数校验：接口入参中，添加了 @Validated 表明，只要在 Student 类中添加对应的参数校验表明，就可以对入参进行自动校验，不合规的参数直接返回缺点信息一览无余：什么进来了，什么出去了，掩护者一览无余目的清晰：熟习 RestFul 的人一看，基本就能知道你这个接口要做什么接口文档：同样的，这种接口可以引入 Swagger 等自动化接口文档工具，可以在开拓的时候花一点点韶光就把接口文档写好，同时更新的时候也只须要该少量的代码5. 写在末了随着技能、项目的迭代，大概这种征象会越来越少直至消逝，但是我想要表达的思想是：
当我们碰着技能时，不能盲目的利用，而是要横向比拟，你得明白，他能干什么，不能干什么，给未来的自己留一条退路大概你不得已在做错的事情，但是你要明白你做的事情是错的，并且努力改动这个缺点，比如做好注释努力用技能武装自己，哪怕你只是在这个行业呆一段韶光，也请你有基本的职业道德，只管即便不给后人埋坑
