近期工作中的一些总结

（1）三层模板和流程
我发现很多东西其实吧，三层就是一个模板和流程；
正向推，从控制层开始，反向从内个sql开始写，大部分应该就是从xml文件开始的，然后写到控制层，毕竟这中间都是方法的调用。

假如先看了前端的接口文档吧，比如要返回什么鬼东西先看一眼；
然后咱们就是说去控制层开始用注解吧；@restcontroller，这种集合性注解；
然后@requestmapping写好请求路径，然后设置好类；继承谁，这个可以自己写个大类，就是有所有的基础请求的这种，这个我进阶的时候可以多看看；
1.写好对前端的接口定义好路径：然后里边写好要用的方法，看看要返回什么，比如前端要一个返回用户列表的数据吧；我们的起名肯定就是getUser()类似这种
2.第二步，我们现在去服务层实现，我们去服务层写个接口就和这个方法名字一样，然后我们里面就写好抽象方法我们再继续，去impl实现层里面实现；
3.实现层我们用到这个方法重写，里面就是返回这个实体类的所有数据，写个return就行了，这个实体类放到集合里面返回，或者直接返回这个实体类的对象？
4.我们去定义实体类，我们这里肯定是user类了，里面id什么的弄好，然后mapper里面写接口，xml里面写对他的sql，用mybatis去映射；
5.然后我们把sql写对，执行一下，去内个数据库里面查一下，能查出来就代表差不多了，其实最重要的就底层逻辑；
6.去前端检验index.ts接口路径是否正确；然后前端的ts里面的字段是否都对都包含。
7.检查完毕之后我们就是去dom里面改，然后把值传对，请求写对；

前端请求 → Controller → Service接口 → Service实现 → Mapper接口 → XML映射文件 → 数据库
↑
返回数据 ←───────────────────────────────────

后端请求 → 前端接口→ 前端ts对应 → 前端vue页面（dom，点击事件，事件逻辑绑定）-> 渲染

其实最重要的就是咱们sql要写好，一个sql就能把查出来的很多东西送进vo类里面；理解的太少了；最好的思路就是从sql到mapper到service

（2）接口复用性
就是一个接口他可以用很多很多很多次；非常多次，比如你做了分页查询吧，下拉框里面根据特殊值查询吧，这种都可以用百万次，而且尤其是用内个id查询数据，你不管什么都是用id，保存其实也是，只是前端给她翻译成字段了，你看着以为是名字，所以要多打断点，多看返回，多理解，然后多看代码；更别说，那种增删改查，你写好一个，别的页面照抄就完了， 主要是逻辑性要很强；根据业务需求来；需求真的多到爆！然后就是，写好了还一会得变，不停的要改；所以根本就是，在写一个初始接口的时候就得写好，做一个最大的功能，其实就在于怎么设计了，如果你底层设计的不好，后面业务开发搭建起来全是bug；

（3）git的使用
就是这个东西吧，他真的就是，很复杂，很烦，很麻烦，你上传了个东西，别人改一样的地方，就冲突，先提交到本地再推送，就容易忘，最好写一个接口测试了没问题就提交，不然多了你根本看不过来，多提交几次，备注打好，每次就一小部分就行了；这样也利于维护，最好遵守规则，写看的懂的代码，不然，更乱，乱种乱；

（4）拿到一个业务先分析，一定要分析好
分析业务需求很重要，比如，现在要加载一个下拉框了吧，就是需求是，你这个下拉框里面有别的表的数据，然后呢，前端用户点击，点击之后我获取到用户的选择和id吧，然后拿到这个值以后，我去根据这个值去查询我对应的信息；这怎么办？先说我的思想：
1.我们需要先对应表建立vo，和实体类，我先把东西查到，查到了我才能返回对吧，返回返回成什么格式呢？就比如这个下拉列表里面要展示的是资产列表，那我就得有个资产表的实体类，然后我去对应建立，然后我给她@data，构造函数和tostring吧，然后全部设置好。那是不是就是封装成这个vo类返回吗；然后返回给mapper给服务层，给控制层，层层返回，然后；就前端拿到了，
2.现在是不是该去xml文件里面写sql了，就是Mybatis,的东西然后做好映射；

（5）解决问题的能力和归类
遇到问题bug不要慌，一定要有特别足够的耐心，然后从源头找，或者报错丢给ai，ai分析完代码返回，找清楚是什么问题谁的问题，效率会更高，再一个就是要多自己手写，自己手写的多了，才能加倍理解，时间紧迫的现在，加上各种

（6）多交流讨论
一定一定要多交流讨论问题，这个东西他原型也有可能会出大问题出错；出很多很多的毛病，遇到很多不清楚的地方就改，然后就是做好一个接口，没问题就提交

（7）总结，然后手敲
一定一定要多交流讨论问题，这个东西他原型也有可能会出大问题出错；出很多很多的毛病，遇到很多不清楚的地方就改，然后就是做好一个接口，没问题就提交，多多熟悉