统一命名字典#
共用含义的字段、属性、表名等，应当尽量统一命名，以减少沟通管理的难度。
例如创建时间，有的命名为cTime，有的命名为gmtCtime，同一种东西却有多种命名，不利于沟通和管理。对于含义相同的，应参考 本表来进行统一命名，对于本表中存在的，不得再额外增加新的名字。
注：
1、标准命名只给出驼峰格式，如果是数据库中使用下划线的，则自行根据驼峰拆出单词转为下划线形势。
2、本表需要大家一起维护，对于其他高频使用的，应及时在此表增加。
image.png
image.png
开发规范#
1 微服务命名规范
规范描述：
微服务应用命名只能使用小写字母和中横线"-"，其他字符均不可以使用，特别是不能使用大写字母命名。
微服务命名需要根服务分类增加前缀，并以中横线"-"隔开。
服务分类包含如下：
image.png
正例：
ai-card-distribute
反例：
loginService 使用了大写字母
mall-cloud-openPlatform 使用了大写字母
2 微服务工程规范
2.1 微服务工程名、Git工程名、pom.xml中的ArtifactId命名 均需要和微服务命名一致，不能再新起一个名字。
2.2 一个GIT工程只能和一个微服务对应，不能在同一个GIT工程中包含多个服务的代码。
2.3 服务的输出JAR包不能包含源代码。
2.4 一个微服务的GIT工程如果有子模块，需要保证服务的运行的JAR输出在 -restapi 结尾的目录中。
3 程序命名规范
3.1. 代码中的命名均不能以下划线或美元符号开始，也不能以下划线或美元符号结束。 反例：_name/name//name
3.2. 类名使用UpperCamelCase风格，但以下情形例外：DO / BO / DTO / VO / AO / PO等。 正例：MarcoPolo / UserDO / XmlService / TcpUdpDeal / TaPromotion 反例：macroPolo / UserDo / XMLService / TCPUDPDeal / TAPromotion
3.3. 方法名、参数名、成员变量、局部变量都统一使用lowerCamelCase风格，必须遵从驼峰形式。 正例： localValue / getHttpMessage() / inputUserId
3.4. 常量命名全部大写，单词间用下划线隔开，力求语义表达完整清楚，不要嫌名字长。 正例：MAX_STOCK_COUNT 反例：MAX_COUNT
3.5. 抽象类命名使用Abstract或Base开头；异常类命名使用Exception结尾；测试类命名以它要测试的类名开始，以Test结尾。
3.6. 枚举类名建议带上Enum后缀，枚举成员名称需要全大写，单词间用下划线隔开。 说明：枚举其实就是特殊的常量类，且构造方法被默认强制是私有。 正例：枚举名字为ProcessStatusEnum的成员名称：SUCCESS / UNKNOWN_REASON。
4 数据库命名规范
5 数据类型约束
数据类型数据库或程序支持得比较多，这里统一约定只能使用如下类型范围：
image.png
典型业务场景与数据类型使用约定：
image.png
6 日志规范
6.1 应用中不可直接使用日志系统（Log4j、Logback）中的API，更不可直接使用有System.out，而应依赖使用日志框架SLF4J中的API，使用门面模式的日志框架，有利于维护和各个类的日志处理方式统一。
6.2 不要使用e.printStackTrace();
6.3 异常日志打印时，带上异常堆栈。
6.4 接口出参和入参及请求头打印，均在iaop中统一封装，业务代码禁止重复打印。
6.5 禁止catch excpeiton后不作任何日志输出，导致异常信息被吞掉。
7 基础组件使用规范
7.1 基础组件引入采用统一版本号管理形式，不能在引入依赖时显示声明版本号。参见：基础组件统一pom版本号管理
7.2 restapi服务必须引入基础组件依赖iboot-starter-restapi-base(该依赖包含spring cloud必要依赖及 iaop、itrace、ilog等基础组件)。以便于后续进行统一灰度控制。
image.png
7.3 MQ的操作统一使用 message-send 组件，便于在灰度控制环境下更友好的使用MQ。参见：02.DSC-MQ-SDK message-send
网友评论