SpringBoot编码规范和命名规则

SpringBoot编码规范和命名规则
SpringBoot项⽬⽬录结构
Java SpringBoot的学习应该是全⽅位的，写这篇博客的起因是由于⼀个⼩插曲。

起初命名schemas下的数据库时，我想当然地将数据库的名字命名为file⽽被同学们纠正过来。

细究下来，才发现SpringBoot项⽬⽬录结构是有命名规范的，编码和命名反映了对应模块的功能。

⼀、规范的意义和作⽤
编码规范可以最⼤限度的提⾼团队开发的合作效率
编码规范可以尽可能的减少⼀个软件的维护成本 , 并且⼏乎没有任何⼀个软件，在其整个⽣命周期中，均由最初的开发⼈员来维护
编码规范可以改善软件的可读性，可以让开发⼈员尽快⽽彻底地理解新的代码
规范性编码还可以让开发⼈员养成好的编码习惯，甚⾄锻炼出更加严谨的思维
⼆、代码仓库规范
（⼀）公共组件
公共组件通常指Java库，提供特定问题的处理程序包
公共组件仓库地址：
公共组件的坐标命名规范
分组编号：<groupId>pany.library</groudId> 固定取值
组件名称：<artifactId>name</artifactId> name根据组件名称定义
组件版本：<version>x.y.z</versio> x.y.z根据组件实际版本情况定义
（⼆）服务组件
服务组件通常指可以独⽴部署，运⾏，维护的服务程序包
服务组件仓库地址：
应⽤组件的坐标命名规范
分组编号：<groupId>pany.server</groudId>固定取值
组件名称：<artifactId>name</artifactId> name根据组件名称定义
组件版本：<version>x.y.z</versio> x.y.z根据组件实际版本情况定义
三、开发环境规范
开发环境：JDK1.7+
开发⼯具：IntelliJ IDEA 2017（安装Lombok Plugin）
构建⼯具：Maven3.x
代码管理⼯具：Git /TortoiseGit
四、项⽬结构规范
（⼀）简述
⼀个项⽬对应代码仓库中的⼀个仓库，项⽬结构是指⼀个基于Maven创建的项⽬⽬录结构。

公共组件项⽬，通常会创建⼀个Maven普通项⽬。

服务组件项⽬，通常会创建⼀个Maven聚合项⽬，并在聚合项⽬⽬录下创建多个继承Maven聚合项⽬的Maven模块，它们⼀起作为服务组件项⽬的组成部分。

（⼆）项⽬名
要求
英⽂名称，作为仓库，项⽬，项⽬根⽬录，组件（公共组件，服务组件）的名称
中⽂名称，⽤于代码仓库的描述
项⽬名称和代码仓库的名称保持⼀致
定义
项⽬名称通常由团队负责⼈确定
⽰例
项⽬中⽂名：⼈脸数据仓库
项⽬英⽂名：data-warehouse-face
项⽬⽬录名：data-warehouse-face
项⽬仓库地址：
初始版本：1.0.0
⽰例是⼀个服务组件，根据上⾯定义的信息确定该服务组件的Maven坐标命名：
<groupId>pany.server</groupId>
<artifactId>data-warehouse-face</artifactId>
<version>1.0.0</version>
（三）模块命名
要求⽰例
模块名称：{项⽬名称}-{模块名称} 模块名称简洁体现职责
模块名字作为模块组件的名称
⼈脸数据仓库的数据接⼊模块名称：data-warehouse-face-access
（四）项⽬⽬录
项⽬⽬录遵循Maven约定⽬录格式
（五）源码⽬录
源码⽬录指：{项⽬⽬录}/src/main/
打包定义⽬录：src/main/assembly
代码⽬录：src/main/java
资源⽬录：src/main/resources⽂档⽬录：src/main/docs
/db：数据库脚本归档
/data：内部依赖数据归档
脚本⽬录：src/main/bin
run-manage.sh 运⾏管理脚本（通过参数start, stop, status, help info控制程序运⾏）sh：服务组件启动脚本
sh：服务组件停⽌脚本
五、编码规范
（⼀）包规范
项⽬基本包：pany.{项⽬英⽂名（较长时适当简化）}.{模块名（可选）}
config：配置类
startup：与服务启动相关的类
client：提供客户端实现的相关类
common：公共类，定义常量类，组件
entity: 数据库相关的实体类
model:数据模型类(参数模型，数据传输模型等）
control:控制层接⼝
service: 服务层
dao：数据库访问层
（⼆）⽇志记录
统⼀使⽤SLF4j接⼝
（三）异常处理
运⾏时异常：通过参数检查等⽅式避免或抛出运⾏时异常，⽇志记录
检查异常：检查异常需要捕获，处理，⽇志记录
（四）接⼝定义
原则
接⼝地址定义表明⽤意
接⼝地址定义清晰，简洁，⽆歧义
同⼀个服务组件的接⼝定义具有⼀致性
格式
控制类的顶层地址格式:/{顶层分类名}，例如：/library ⼈员库相关接⼝的顶层地址
接⼝定义使⽤Swagger的API注解说明
标注完整的请求信息，请求⽅法，请求地址，参数可选性，接⼝描述请求⽅式
GET URL-Params
POST Form-Data
POST RequestBody(JSON格式)
POST Mulitpart
响应⽅式
统⼀的响应模型
（五）辅助⼯具
字符串处理：apache common-lang3
时间⽇期处理：joda-time
JSON处理：Gson，Fastjson
集合扩展⼯具：guava
⽂件和流处理：commons-io
编解码：commons-codec
建议：尽可能使⽤开源组件
（六）代码注释
类、接⼝、枚举顶层注释
接⼝⽅法注释
静态⽅法注释
公开⽅法注释
类的属性字段注释
常量注释
不限于以上
六、代码控制规范
（⼀）拉取原则
强制
每⽇开始⼯作拉取
约定
提交之前拉取
（⼆）提交原则
强制
提交代码必须构建成功（⽐如：编译，打包成共）
提交代码必须完整（⽐如：少提⽂件）
提交代码必须忽略到本地临时⽂件（⽐如：target, logs, .idea, *.iml,dist 等）约定
完成⼀个功能提交
修改⼀个Bug修改提交
解决冲突提交
每⽇结束⼯作提交
（三）提交注释
强制
中⽂填写注释
注释反映本次提交变更情况
约定
注释描述添加前缀，前缀如下
[创建] 通常在项⽬创建时使⽤
[新增]
[修改]
[删除]
[修复-number] 修复Bug使⽤，number是Bug编号
七、构建规范
（⼀）公共组件构建规范
构建输出组件包
构建输出组件源码包
构建发布到公司私有仓库
（⼆）服务组件构建规范
服务组件包命名：{组件名称}-{版本号}-bin.zip
构建输出到⼯程根⽬录下的dist/{组件名称}-{yyyyMMddHH}⽬录。