1.请求路径命名
有时候想根据URL快速的找到该controller时,但是在全局搜索的时候会查找到很多一样的方法、变量，相信各位都碰到多，无法快速定位到该请求，所以这个时候可以在请求路径名称前加一个 /,这时候搜索/url就可以很快的分离出请求类，例如：
@RequestMapping("/DispatchCheck")
public class DispatchCheckController {@PostMapping("/getList")public void getList(){}
}
2.命名规范和业务代码尽量写一块
博主现在接触的一个EMS项目。项目中的service继承了公司封装的service,而封装的service又继承了MyBatisPlus的IService，用过MyBatisPlus肯定都熟悉它的IService中有一些基本的增删改查方法，直接使用Lambda写法加封装的service方法用起来方便，所以项目中很多业务代码都写在了controller中，但这不是我要吐槽的，看了你就知道了代码如下
在该接口是个创建接口并且前面还有一堆逻辑的情况下，博主下意识就会认为 produceReportService.create(entity); 这个方法就只是一个插入的作用，但是他在service的create方法中藏在一段其他的业务的代码，这让博主想到以后看代码还得每个service方法都点进入看一看吗，这获取有点太耗费时间了，所以博主觉得最好还是根据功能的不同命不同的名称，create就只干创建的事，求他的功能拿出来或者重新写个方法，别放一起
3.表的关联字段
在开发中，一般子表关联主表都会关联主表ID，或者A表要查另B表的数据会关联上B表的ID,但是一般表都会有一个唯一的code作为显示的标识，不可能把id显示出来作为标识，这时候往往只需要另一个表的编码或者名称来显示而已，根据ID关联就要联表查，所以博主觉得都是唯一的，那为什么不用code作为关联字段呢，只需要编码的时候就不用再去联表了，节省了数据库的开销，并且在排查数据的时候一般也是根据code来查看，看到code一下就能找到，而不用再去联表查看