【无标题】

Controller规范

• 设置统一的Result对象

返回值有String、Map<String, Object> 、JSONObject等，返回值不统一，真是惨不忍睹。

https://blog.csdn.net/qq_41633199/article/details/105351898

• controller不需要打印日志，建议日志在service层打印

• Result只给controller用，不传递给service或impl

代码可读性下降

• controller传递给service的数据类型尽量是bean或者String

不要直接传递request。参数格式转换在controller里做

// 将字符串类型转化为对象
model appExtendInfo = JSON.parseObject(extend, model.class);

日志打印

• 修改（包括新增）操作必须打印日志

• 主要方法的入口，添加日志

• 条件分支必须打印条件值，重要参数必须打印，比如：Type、Status

• 数据量大的时候需要打印数据量

工具类编写规范

正则表达式验证工具类RegexUtils.java
https://www.cnblogs.com/lr393993507/p/5234857.html
​
Google Guava 优雅的参数验证（Preconditions）
https://blog.csdn.net/csdnlijingran/article/details/97684429

• 定义自己的工具类，尽量不要在业务代码里面直接调用第三方的工具类

可以对第三方的工具类进行在封装，不同的人会使用不同的第三方工具库，会比较乱。

• 工具类尽量抽象出来，支持多种参数类型

• 使用重载编写不同参数类型的函数组，支持多种参数类型

• 工具类单独存放于common/util里文件夹中，区分其他文件夹

函数编写规范

• 不要出现和业务无关的参数

request，Response，非常干扰阅读，一堆无关的参数把业务代码都遮掩住了，函数不好测试

• 避免使用Map，Json这些复杂对象作为参数和结果

定义实体类，少用map或json。

• 把可能变化的地方封装成函数，函数尽可能小

方法中可能变化的地方，抽出一个函数，加上注解。即减少一个方法中的行数，又便于修改。