以下为以前开发自己设定的一些规范，供以后参考

1. 返回类型

1. 所有接口返回类型都为ResponseMsg
2. 除了与外界交互的接口,不允许其它返回类型为ResponseMsg的方法

2. 对外接口请求路径规则

1. 提供给app用的接口统一以[/app]开头
2. 提供给外部系统调用的接口统一以[/api]开头
3. 提供给页面的接口统一以[/page]开头

异常处理

1. 异常处理不需要手动输出日志
     - 全局异常处理会帮你做这件事
2. 遇到的所有异常都包装成[业务异常]or[系统异常]后往上抛
3. 业务异常(校验异常等) 对应类:BusinessRuntimeException
     常用方法:
     1. throw BusinessRuntimeException.buildBusyException(EnumCommomSysErrorCode.MQ_ERROR, “消费异常”, parm);
     2. throw BusinessRuntimeException.buildBusyException(parm,EnumCommomSysErrorCode.MQ_ERROR,);
4. 系统异常(404,MQ联不通等) 对应类:SystemRuntimeException
     常用方法:
     1. throw SystemRuntimeException.buildSysException(EnumCommomSysErrorCode.FILE_TYPE_NOT_SUPPORT, e, parm);
     2. throw SystemRuntimeException.buildSysException(EnumCommomSysErrorCode.FILE_TYPE_NOT_SUPPORT, “文件类型不支持”,e, parm);

业务日志打印

1. 对HTTP请求(Controller)进来参数,不需要打印(对于Dubbo/MQ等入参还是需要打印的)
     - 已经做了拦截器全局进行打印

脚本提交

统一使用Flyway进行统一的管理
svn://172.16.30.16:20044/G2G_DS/trunk/WMS/wms_db_script

Dao操作相关

1. 对数据库表更新/删除操作不能使用ID作为’第一’条件, 如

   错误用法

   1	update parcel set a="value" where id=123

   正确用法 应用业务主键作为条件

   1	update parcel set a="value" where fpxTrackingNo="fpx20190402"

2. 数据库查询不允许使用select *, 应使用select a,b,c

MQ队列命名规范

1. 业务线_队列的生产者项目名_消费的项目名称_[Q/R/X]_自定义标识
   如 : GDS_WMS_WOS_Q_FORECAST
     对应的Exchange名为:GDS_WMS_WOS_X_FORECAST
     对应的Routing key名为:GDS_WMS_WOS_R_FORECAST
   ;
     对应的死信队列名为:GDS_WMS_WOS_Q_FORECAST_DEAD
     对应的死信Exchange名为:GDS_WMS_WOS_X_FORECAST_DEAD
     对应的死信Routing key名为:GDS_WMS_WOS_R_FORECAST_DEAD
2. 生产者队列的消息统一通过 [MQ的shovels插件] 转发到消费者队列
3. 生产者不需要创建死信队列
4. 消费者队列必须测试一下消息失败是否会进入对应的死信 这,很重要

MQ队列/Exchange 定义规范

1. [生产者端]需要定义队列+Exchange 并且建立队列和Exchange的绑定关系

   • 队列需要定义:

     durable=true
     exclusive=false, autoDelete=false
     队列创建使用rabbitAdmin.declareQueue(queue); 防止队列窜到别的VH中

   • Exchange 需要定义

     durable=true
     autoDelete=false
     Exchange创建使用rabbitAdmin.declareExchange(exchange);防止队列窜到别的VH中

   • 建立绑定关系

     rabbitAdmin.declareBinding(BindingBuilder.bind(queue).to(exchange).with(“GDS_WMS_WMS_R_TASK_ASYNC_CONSUME”));

例子

待办目录

• [X] 基于Junit5的新测试用例规范
• [ ] 基于新测试用例的demo
• [ ] MQ重复消费问题解决
• [X] 根据请求ID追踪调用链所有日志

系统改造

• [ ] 新建GDS公用工程,存放Wms与Wos公用代码(暂定)

redis缓存Key规范

1. Key前缀统一使用常量:
   ConstantsString.RedisConstant.REDIS_CACHE_PREFIX

关于测试类的规范 (暂定)

1. 单元测试应该是不依赖于别的单元测试的
2. 所有单元测试应该都得回滚，如果存在异步处理的情况，应尽可能把主线程与fork线程拆成2个测试类方法进行测试
3. 每个测试类／测试方法应写上对应的名称@DisplayName
4. 每个接口，都必须写一个正向测试方法
5. 关于测试类的类名：测试类与被测试的类的路径需要一致，名字也需要对应，如：

1
2
3

com.fpx.wms.service.impl.InstockServiceImpl
↓对应↓
com.fpx.wms.service.impl.InstockServiceImplTest

6. 关于测试类的方法名： 方法名尽可能为成功的条件如shouldSuccessAfterPay()，而方法具体用来测试哪个场景的，我们已经使用了@ DisplayName来描述，无须担心
7. 对于结果，需要适应assert断言输出与结果是否一致（这才能算是一个单元测试）
8. 断言统一使用AssertJ框架，使用Assertions.assertThat()进行处理

可以参考\gds-parent\gds-wms-parent\gds-wms\src\test\java\com\fpx\gds\wms\service\exceptionhandle\impl在SVN版本为2962时提交的代码为参考

• 目录接口篇
• 接口篇
• 异常处理与日志篇
• 数据库篇
• MQ篇
• Redis篇
• 单元测试篇