引言：
网上很多开发规范又臭又长。实际工作中的一些习惯，编个号，就记了下来。
1 更新日志
2 数据库规范（表、字段）
- 表命名，按照“项目简称_业务名称”，且表命名应具备“具义化”的特征，且不用的英文含义之间使用下划线 _ 连接，统一使用小写字母命名。例如需要新建一张“博览中心项目”的人员表，表命名：niec_person
- 若非必要，不得给表和表之间建立外链关系。
- 表与表之间存在关联性时，关联字段需要保持一致，关联字段具义化。
- 建表必须要包含 create_time、create_by、update_time、update_by、remark 五个字段。
- 字段命名，应具备具义化的特征，且不用的英文含义之间使用下划线 _ 连接，统一使用小写字母命名。
- 字段释义，若需要使用括号，请使用中文括号。
- 枚举字段的释义，若涉及对枚举值的解释，中间用 - 分隔开来，例如：学生类型（1-班长 2-数学学习委员 3-语文学习委员 4-英语学习委员）
- 定义枚举值时，若存在 “是否” 的业务意义时，0 永远代表 “否”，1 永远代表 “是”。
- 使用国产数据库时，不能手动填写自增主键ID。
3 编码规范
3.1 类、方法、变量
- 类名、方法名、变量名（包括但不限于 list 、map 、枚举、常量等），尽量写明其作用。
- 类名、方法名、变量名具义化，不要用类似 “aaa”,“one”,"111"这样毫无意义的命名方式。
- 类名首字母必须大写，严格遵循大驼峰的命名规则。
- 方法名首字母必须小写，严格遵循小驼峰的命名规则。
- 方法的第一个大括号应该紧跟着小括号后面，不得换行。
- 在一个方法中，尽量避免对变量的操作或新增临时变量，减少对内存空间的使用。例如：在做一个查询学生信息的功能，若查询出来的字段满足业务需要，可以直接在 service 层的方法中 return studentMapper.selectStudentList(Student student); 不需要先把结果赋值给 studentList 再 return 。
- 无用的代码、无效引用（包括引用包，声明的变量等）尽量删除。
3.2 关于注释
- 区分文档注释和行注释，行注释需要尽可能的多，特别是涉及复杂逻辑时。类和方法使用文档注释。
- 配置文件（xml、proprety、yml），除通过自动生成的代码，新增的内容尽量都把注释加上去，哪怕是一眼能看出该方法是干什么的，也得加。
3.3 日志打印
- logger是日志打印，不是注释，不能充当注释。
- 不要使用System.out.println()打印日志，尽量使用info或者debug、error等符合标准的日志打印方式，一般使用info级别。
- 在开发环境中，可以通过增加一些不必要的日志打印进行调试。但是到了生产环境，要尽可能的减少日志打印，“能删尽删，应删尽删”。否则会影响生产环境的应用运行性能。
- 避免输出大批量的日志，这样的打印无意义。比如：打印查找一万条数据的结果集。部分业务层面的关键日志可以打印。
3.4 mybatis 的相关
- mybatis 的 mapper.xml 文件中，涉及多个字段的查询，得换行，结构清晰化。
- mybatis 的 mapper.java 文件中，操作数据库的方法参数中带 @param 的，超过三个参数得换行，结构清晰化。
3.5 通用
- 建议将 create_time、create_by、update_time、update_by、remark 这五个字段封装到一个基类中，后续的实体类均继承该类。
- Controller代码尽量少，尽量避免在 Controller 层的方法中编写业务逻辑，把业务逻辑尽量都放到service中。
- Controller 中的接口统一请求方式如下：
- 查询：使用 GET 请求方式
- 新增：使用 POST 请求方式
- 修改：使用 PUT 请求方式
- 删除：使用 DELETE 请求方式
- 统一分页参数
- 请求参数统一使用 pageSize 、pageNum
- 返回参数中的总条数统一使用 total