开发规范

关键

针对框架和团队现状，特此梳理了开发规范。这些都是强制要求，以保障项目质量

变量与方法命名规范

使用准确的英文命名，命名遵循小驼峰命名法，首字母小写。
确保英文拼写正确，IDE（如 IntelliJ IDEA）会自动标识拼写错误。
方法和变量命名需清晰、有意义，无需注释即可理解其用途。禁止使用简写，如：
CompanyMatchPolicyPageResultDTO->CMPPRDTO。

代码格式化后提交

避免无用空行，使用格式化工具自动移除多余空行。
及时删除无用的大段注释代码，必要时可通过 Git 历史记录恢复。
移除无用变量，无用的引入的包（在代码中显示灰色的部分）等，如：
在使用链式表达式时，单行代码不宜过长

//太长了，换行
baseService().lamadaQuery().eq(User::getName, "张三").eq(User::getName, "张三").eq(User::getName, "张三").eq(User::getName, "张三").list();

//这样看的清晰很多
baseService().lamadaQuery()
    .eq(User::getName, "张三")
    .eq(User::getName, "张三")
    .eq(User::getName, "张三")
    .eq(User::getName, "张三")
    .list();

使用合理类型作为方法参数

Controller层接收@RequestParam和@RequestBody两种类型的参数。

@RequestParam用于接收单个参数，此时应该使用GET请求处理。

@GetMapping("/method")
// 建议不超3个参数，太多参数建议使用@RequestBody接收
public Result method(@RequestParam Long id, @RequestParam String name) {
    return Result.OK();
}

@RequestBody用于接收复杂参数，此时应该使用POST请求处理，以JSON格式放在请求体中传递，并且使用实体类（DTO/Params/Entity）接收。对于参数比较多的情况，应该使用此方式传参
```
 @PostMapping("/update")
 public Result update(@RequestBody CdoBaseAbility entity) {
     return Result.OK();
 }
```

严禁在方法间使用Map，Object等不定类型传参，这一类参数在方法间传递，无法明确定义参数的变量，会增加代码阅读难度，不利于后期维护。

UserService负责了sys_user用户表的增删改查操作，但updateById(User user)这个原生操作被人重写了。重写updateById的逻辑后会把user对象的password字段取出来，进行加密后再存入数据库。此时不知情的开发者在其他Service层调用userService.updateById(user)，可能只想更新下用户的姓名或者手机号，但是一旦调用了之后，用户密码就被二次加密了，导致用户登录时提示密码错误。而且哪怕别人知道重写了，也没有别的方法可以去更新user了，只能手写SQL去更新。

禁止重写Service层中，原生提供的原生无业务方法，包括但不限于：


boolean save(T entity);

boolean update(T entity);

boolean updateById(T entity);

boolean removeById(Serializable id);

//还有很多其他方法...

这些方法是Mybatis-Plus基于表，自动实现的原生CRUD方法，使用频率非常高，且不包含任何业务逻辑，一旦重写后，其他Service便没有办法调用原生CRUD方法
同时，其他Service层并不知道你重写的方法，如果此时还去调用原生方法，则会出现不可预知的后果

Service 层方法不得耦合其他业务逻辑

禁止方法直接调用其他业务方法，以免修改时影响多个业务。
判断是否可以跨业务调用的标准：方法是否为特定业务定制（针对性）或通用于多场景（通用性）。定制方法（如含业务实体或操作的命名）不可跨业务调用。如果方法轻量或与业务完全无关，则允许调用，例如数据字典的 getByCode(String code)。（实际开发过程中，除了上一点中提到的原始方法，其他方法几乎都不能跨业务调用）
关键
这一条的关键是把握好方法“是否轻量、通用”的度