讨论帖！手机端的开发过程中，如何从代码设计层面更有代码接口的管理？？持续更新

问题：在手机端的开发过程中，我们经常会遇见由于需求业务发生变化，导致后端的接口形式发生了变化，那么我们能不能从代码框架设计层面灵活的管理维护代码呢？

目标：通过代码框架的设计，让开发人员能够更加好的去维护，管理每个代码的版本，让自己的项目也变得比较优美。

例如：
1：小程序的发布存在时差或者缓存，当前用户版本是1.0 你的服务端的版本可能是1.1 了，假设部分接口发生变化，会导致1.0的用户可能无法使用（如果是支付模块），让用户体验度下降

2：APP的版本更新，可能部分用户不及时更新版本，也会导致服务异常（虽然可以每次用户打开APP校验版本要求强制更新）

问题归类：
变化形式有如下2大类种，有几个小类别

接口形式发生变化
1. 接口入参个数调整，由以前的1个，2个变成了N个
2. 接口请求发生发生变化，由GET换成POST 或者POST换成GET
代码层逻辑发生变化
1. 查询的业务方法（Service层）发生了变化
2. 查询的数据库的Mapper 发生了变化

在开发的过程中，还有很多很多各种各样的问题，我只列举我遇见到的问题，如果有大神补充的，我也会及时更新上去。

解决思路：

针对目前列出2个大类，我自己想到了一部分自己初略的思路；（从外往内的整理思路来解决的）
问题1.接口形式发生变化时，参数个数发生了变化，这个时候，我们会使用重载的方式来通过参数的个数来控制接口不同的请求业务逻辑；
问题2的情况其实也是一样的，我们可以copy 1个出来，只是简单的把请求方式换成POST，这样就可以动态的根据请求不同来查询不同的Controller

原文链接：https://blog.csdn.net/CC_LIM/article/details/84313390

    @RequestMapping(value = "index")
    @Version(curVersion = DcDhptApplication.V_1_0)
    public ModelAndView showIndex(HttpServletRequest request) {
        ModelAndView view = new ModelAndView("index");
        RequestContext context = new RequestContext(request);
        String indexTitle = context.getMessage("index.Body.title");
        view.getModel().put("IndexTitle", indexTitle);
        return view;
    }

    @RequestMapping(value = "index", params = "id")
    @ResponseBody
    @Version(curVersion = DcDhptApplication.V_1_2)
    public Object showIndexJsonById(HttpServletRequest request, Integer id) {
        Map<String, Object> maps = new HashMap<>(2);
        RequestContext context = new RequestContext(request);
        String testMsg = context.getMessage("index.Body.testMsg");
        maps.put("status", 200);
        maps.put("info", testMsg);
        maps.put("msg", id);
        return maps;
    }

    @RequestMapping(value = "index", params = {"id", "imgBase"})
    @ResponseBody
    @Version(curVersion = DcDhptApplication.V_1_3)
    public Object showIndexJsonByIdAndImgBase(HttpServletRequest request, Integer id, String imgBase) {
        Map<String, Object> maps = new HashMap<>(2);
        RequestContext context = new RequestContext(request);
        String testMsg = context.getMessage("index.Body.testMsg");
        maps.put("status", 200);
        maps.put("info", testMsg);
        maps.put("msg", id);
        maps.put("imgBase", imgBase);
        return maps;
    }

随着业务的变化（万恶的产品~~~），我们需求会不停的发生变化，如果这个代码当初不是你维护的话，你可能需要去需要依赖于前端实际调用的方法，来通过1对1的代码搜索来确认这个接口是否在使用；
例如：/index 是1.0的版本 /index?id=1 是1.1的版本 /index?id=1&imgBase=2是 1.2的版本；
由于我们之前编写代码的时候，没有编写注释，到了后期，代码的整洁度非常的低；

这时，我采用了自己定义注解@Version的方式，人为标记当前接口的版本号是属于哪个版本。同时从公司管理层面要求对应的开发人员必须遵循一定的开发规则。
没有用注释而用注解的想法是，以后我们可以通过注解的方式来完成一些更棒的想法

以上这个方法解决了如下问题
1. 前端不需要改动接口名称，只需要在前端程序调整入参即可
2. 从后端的最外层，能快速的标记当前接口的版本，方便自己处理

PS：对于入参的个数调整，我也想到了一种非常非常粗暴的方式，那就是全部用POST请求
，入参用 JSONObject 接收，但是非常不推荐用这种方式；因为这样对入参的代码查阅非常非常不好。

    @RequestMapping(value = "searchDMgoodslist", method = RequestMethod.POST)
    @Version(curVersion = DcDhptApplication.V_1_6)
    public ObjectRestResponse searchDMgoodslist_v3(@RequestBody JSONObject jsonObject) {
//    Xxxx 业务代码
    }

----------------------------------------------------------分割线----------------------------------------------------------

以上的这方式，其实在实际的变化量，也是比较少的；在更多的变化中，我们可能是入参没有发生变化
但是底层的Service 的逻辑发生了翻天覆地的变化（如果这个接口不是你维护，那就是雪上加霜）。

这个时候，我可能会直接从Service 层全部重写；
例如，有1个Service 的名称叫 findUserAll() 获取所有的用户信息
由于查询用户的时候，我需要逻辑进行调整。
（感觉这个比喻不太好，但是想表达的意思是，当你无法直接去修改原方法的时候，更多的可能是会去重写写1个新方法）
这个时候，我会重写写1个 findUserAll_V1_2(）的方法。然后再Controller 直接调用我我新写的方法；
在这样的积累性，代码的层面也非常不整洁，很多你完全不知道用不用的代码；
在这种情况下，去维护代码，成本也会非常的高

针对此问题想到了如下几个解决思路
1：在前端的请求头中存储Version版本号参数，在我们的Controller 层或者Service 层人为根据版本号来切换不同的Service层业务方法；
在这种情况下，我们保持了 Controller的入口不变，只需要通过内部的方法控制，来维护代码版本；那么在这种长时间的版本累计下，我们要删除以前废弃的版本时，让其中的可读性变得相对比较好；

缺点：可能有些Service 或者内部Dao 层又相互耦合依赖，部分方法依旧无法美好的剥离

对于业务层，我想到了2个方式来管理版本控制
在请求头里面加Version 参数？？？在代码的包里面 Controller 与 Service 层中新建 1个版本包？

又想到了一个

疑问？
我们控制了版本，会产生大量的重复代码，那么我们肯定会定期清理，如何快速的整理这些不必要的代码呢？？

也请各路大神，有相关参与经验能多多分享；分享的同时，也是大家一起学习的过程！

来源：CSDN

作者：qq_17230375

链接：https://blog.csdn.net/qq_17230375/article/details/103241787

标签

代码管理

用户接口

版本管理

软件