这两天一直在对之前做的工作做梳理总结，不过前两天我都是在总结一些bug的问题。尽管有些bug问题我还没写文章，但是，我今天不得不先停下对bug的总结了。因为在国庆之后，我需要自己开发一个IT资产管理的功能，这个功能需要你写大量的接口。所以今天，我就把过去这几个月写的几个接口拿来复习一下，为之后写更难的接口做准备。
了解需求
看这个问题：左图的干系人那块地方不知道为什么出现这些数据。我们希望达到右图这种效果，就是干系人那块地方显示这个设备关联的所有干系人，然后每个干系人都可以显示这个干系人下所有的用户。
大纲思路
把需求捋清楚，知道要干什么了之后，就想想大致的思路怎么写。我们需要写一个接口，这个接口的返回数据是：返回所有干系人以及干系人下的所有用户。返回值是这个样子的：
[{"name": "生产部经理","list": [{"name": "张三","mobile": 123456789877},{"name": "李四","mobile": 123456789877},{"name": "王五","mobile": 123456789877}]},{"name": "工序段段长","list": [{"name": "陈六","mobile": 123456789877},{"name": "黄七","mobile": 123456789877},]}
]只要后端传回来这些数据，前端就可以用这些数据来做展示，呈现在页面上。
后端代码编写
写返回值
这个时候，一个接口的返回值就已经装饰好了，接下来就是修改内部了。
写controller层
在修改内部之前，我们首先要知道这个接口的逻辑是什么？逻辑是：通过设备ID找到关联这个设备的所有干系人，再从每个干系人找到关联这个干系人的所有用户。
“通过设备ID找到关联这个设备的所有干系人”的代码其他接口已经写了：
接下来写“从每个干系人找到关联这个干系人的所有用户”：
最后的效果：
总结一下这个代码的意思：
//通过设备ID找到关联这个设备的所有干系人
List<RoleInfoDTO> result = deviceStakeholderService.getDeviceStakeholderOption(deviceId);在小程序故障上报的地方，你选了设备，干系人数据就直接出来了。证明什么？证明通过设备才能找到干系人用户。这就是第一行代码的意思。传入了deviceId，返回RoleInfoDTO（里面是所有干系人的信息，比如说有3个干系人，就返回3个干系人的所有信息）。
List<StackholderUsersInfoVO> list = new ArrayList<>();自己创建一个list对象，这个list对象是真正的返回给前端的对象，这个对象的类型是StackholderUsersInfoVO。
@Data
@ApiModel("干系人角色的信息")
public class StackholderUsersInfoVO {@ApiModelProperty("干系人角色名")private String name;@ApiModelProperty("干系人角色下的每个用户的信息")private List<UserInfoVo> list;
}接下来，我们的任务就很明确了：你写的代码是关于如何找到干系人角色名（name），以及干系人角色下的每个用户的信息（list）。往后你的每一段代码，目标都是关于拿到name和拿到list，最后return list就好了。
name和list从哪里拿到呢？肯定是从result对象里拿。你第一行代码已经拿到了所有干系人的信息了，然后放到result对象里。下一步就是操作这个result对象，拿到这个对象的干系人角色名以及每个干系人的所有角色。那就写吧：
//遍历result中的每个干系人
for(RoleInfoDTO roleInfoDTO : result) {//创建一个对象a，对象a是StackholderUsersInfoVO类型的，我们希望把从result对象中查出来的数据放到对象a中，所以要创建一个对象aStackholderUsersInfoVO a = new StackholderUsersInfoVO();//把result对象中的干系人角色名拿出来放到对象a中a.setName(roleInfoDTO.getRoleName());
//通过干系人ID找到干系人下的所有用户，用户的信息放到userList对象中List<UserInfoVo> userList = iUserInfoService.getUserInfo(roleInfoDTO.getId());//把userList对象放到对象a中a.setList(userList);
//把对象a放到对象list中list.add(a);}已经大功告成了，最后把list对象返回就好了：
return Result.success(list);其实你把controller层写好后，你发现service层，mapper层，sql语句都写好了。为什么？因为我是复制粘贴代码过来的，当时写这些代码的人早已经把service层，mapper层，sql语句都写好了，我只要复制一个controller层，相当于变相把其他的这些都复制过来了。
接下来，可以用postman测试一下，看看这个接口是否返回了我们想返回的参数：
用postman测试知道已经返回成功了，证明这个接口后端已经写完了。
进去小程序看看这个接口在不在：
发现还是不在。为什么呢？Postman明明已经试过这个接口已经在，而且返回的参数值确实是我们想要的，但是为什么在小程序就不在呢？
因为我们还没有配置连接到后端的接口的小程序代码，先配置一下：
然后再去看看小程序端的接口那里有没有显示出来我们写的这个接口：
OK，已经看到了，正是我们想要的，因此后端已经完成了。
前端代码编写
总结
今天我们讨论了如何编写接口。其实，在这几个月的实践中，我逐渐领悟到了一些关键点。
当你需要编写一个接口时，最重要的部分并不是代码的具体实现，代码的细节等，而是你需要彻底理解这个接口的每一层逻辑。也就是说，你需要非常熟悉Controller层、Service层和Mapper层每层都要干嘛。
只要你对接口每一层的功能和逻辑了然于心，你就可以将你的思路和想法传达给AI，让AI来帮助你写。坦白讲，其实你自己写的不一定有AI写的漂亮。
就以这个接口为例子：
你把你的这个思路给AI，AI帮你写。当然，AI生成的代码肯定和我们最终的代码还是差一点的，这时候你需要做的就是理解AI的代码逻辑，并进行必要的修改。即使你不擅长写代码，但只要你能看懂并修改代码就可以了。不然的话，如果连修改代码都不会，那还不如转行算了！
所以，我的工作重点在于理清接口每一层的逻辑，然后将这些逻辑告诉AI，让AI来生成代码。在AI生成代码后，我再根据实际需求进行调整。如果遇到实在解决不了的问题，就去找睿哥，让他帮我修改就好了。
