编码规范
-
设置统一的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。
-
把可能变化的地方封装成函数，函数尽可能小
方法中可能变化的地方，抽出一个函数，加上注解。即减少一个方法中的行数，又便于修改。
