Java规范

Java开发规范

命名风格:

1.【强制】项目命名：使用英文小写并且使用”-“隔开，例如bsmis-develop-doc很明确的就是开发文档等

2.【强制】包命名：com.bsmis+【系统（sys）】+【模块（user）】+【功能（controller\serves\impl\mapper\entity\utils）】等

3.【强制】类命名：全英文并符合驼峰命名，例如：SysUserController、SysUserService、SysUserServiceImpl、SysUserMapper等

后缀：*Controller 控制层，处理请求相关例如：SysUserController 后缀：*Service 服务接口，提供业务服务的方法定义例如：SysUserService 后缀：*ServiceImpl 服务类接口实现，并且实现了具体方法例如：SysUserServiceImpl 后缀：*Mapper 封装了数据访问方法例如：SysUserMapper 后缀：*Interface 这是一个接口类例如：FileInterface 后缀：*Listener 监听类，响应某种事件例如：PaymentSuccessListener 后缀：*Event 事件类，代码某种事件例如：PaymentSuccessEvent 后缀：*Factory 工厂类例如：PaymentOrderFactory 后缀：*Adapter 适配器：用来链接以前不被支持的对象（适配器模式）例如：PaymentOrderAdapter 后缀：*Wrapper 包装类：为了给某个类提供没有的能力例如mybatis-plus：LambdaQueryWrapper 后缀：*Job 定时任务例如：SysUserJob 后缀：*Util 工具类:一般是静态方法，可以直接调用例如：RequestUtil.getReqest()

4.【强制】方法命名：方法的名字的第一个单词应以小写字母作为开头，后面的单词则用大写字母开头。例如： sendMessge

函数方法常用的动词:

get 获取/set 设置, insert 插入/delete 移除, add 增加/remove 删除 create 创建/destory 移除 import 导入/export 导出, start 启动/stop 停止 open 打开/close 关闭, read 读取/write 写入 load 载入/save 保存, send 发送/receive 接收 start 开始/finish 完成 create 创建/destroy 销毁 begin 开始/end 结束, backup 备份/restore 恢复 import 导入/export 导出, split 分割/merge 合并 select 选取/mark 标记 undo 撤销/redo 重做 clean 清理/clear 清除, index 索引/sort 排序 find 查找/search 搜索, 5.【强制】Mapper方法命名

为了更好对数据库的读写分离的支持，对Mapper方法命名有以下要求；主库-write:Mapper中方法名必须以insert\update\delete开始；例如：

    public interface SysUserMapper extends BaseMapper<SysUser> {
        public boolean insertUser(User user);
        public boolean updateUser(User user);
        public boolean deleteUser(String userId);
    }

从库-read:Mapper中方法名必须以select\get开始；例如：

    public interface SysUserMapper extends BaseMapper<SysUser> {
        public boolean selectUserById(String userId);
        public boolean selectOne(User user);
        public boolean getUserById(String userId);
    }

命名不符合规范时默认使用主库

6.【强制】Restful接口规范：

GET：读取（Read）示例： GET /system/user/1 根据id获取用户 GET：读取（Read）示例： GET /system/user/page?current=1&size=1 根据查询条件获取分页数据 POST：新建（Create）示例： POST /system/user/insert 新增加用户 POST：更新（Update）示例： PUT /system/user/update 修改用户 POST：删除（Delete）示例： POST /system/user/delete/1,2,3 根据ids删除用户

http://127.0.0.1/system/user/{id} GET 根据用户id查询用户数据

http://127.0.0.1/system/user/insert POST 新增用户

http://127.0.0.1/system/user/update PUT 修改用户信息

http://127.0.0.1/system/user/delete/1,2,3 DELETE 删除用户信息 OR http://127.0.0.1/system/user/{id} DELETE 删除用户信息

1、应使用连字符（ - ）来提高URI的可读性 2、URI路径中全都使用小写字母 http://127.0.0.1/system/sys-user-role/update http://127.0.0.1/basedata/dat_address_type/update http://127.0.0.1/basedata/dat_address_type/add

7.【强制】Redis缓存使用规范

Key名称使用系统名+模块名+业务名，冒号分隔，系统名:模块名:业务名;例如：bs:sys:user value 缓存值不宜存入太大的数据设置合理的过期时间

异常规范：

【强制】业务系统抛出异常必须使用统一的异常。

BaseException 基本业务异常 AuthBaseException 授权异常 DataBaseException 数据库异常示例：throw new DataBaseException("未配置数据库密码");

日志规范：

【强制】日志文件推荐至少保存 15 天，因为有些异常具备以“周”为频次发生的特点。

@Slf4j //类上增加注解，类中直接打印对应级别的日志,并且要判断日志级别中打印

    if (log.isDebugEnabled()) {  
       log.debug("项目{}，模块{}，msg{}","demo","route","路由表分页查询");  
    }  
    if (log.isInfoEnabled()) {  
       log.info("项目{}，模块{}，msg{}","demo","route","路由表分页查询");  
    } 
    if (log.isWarnEnabled()) {  
       log.warn("项目{}，模块{}，msg{}","demo","route","路由表分页查询");  
    }  
    if (log.isErrorEnabled()) {    
       log.error("项目{}，模块{}，msg{}","demo","route","路由表分页查询");  
    }  

log4j定义了8个级别的log（除去OFF和ALL，可以说分为6个级别），优先级从高到低依次为：OFF、FATAL、ERROR、WARN、INFO、DEBUG、TRACE、 ALL。
Log4j建议只使用四个级别，优先级从高到低分别是ERROR、WARN、INFO、DEBUG。

代码格式:

【强制】if/else等代码块必须使用包裹，方便代码理解，不能省略

单元测试:

【强制】好的单元测试必须遵守 AIR 原则。

说明：单元测试在线上运行时，感觉像空气（AIR）一样并不存在，但在测试质量的保障上，却是非常关键的。好的单元测试宏观上来说，具有自动化、独立性、可重复执行的特点。  A： Automatic（自动化）不需要人力来判断正确或者错误  I： Independent（独立性）不可以来别的环境的正常运行来运行单元测试  R： Repeatable（可重复）可以多次重复执行

【强制】单元测试应该是全自动执行的，并且非交互式的。

测试用例通常是被定期执行的，执行过程必须完全自动化才有意义。输出结果需要人工检查的测试不是一个好的单元测试。单元测试中不准使用 System.out 来进行人肉验证，必须使用 assert 来验证。

为什么？与自动化原则相符合，如果我每次运行脚本都需要人肉看一下，自动化测试就是为了减少认为改错，所以要尽力避免 3. 【强制】保持单元测试的独立性。

为了保证单元测试稳定可靠且便于维护，单元测试用例之间决不能互相调用，也不能依赖执行的先后次序。反例： method2 需要依赖 method1 的执行，将执行结果作为 method2 的输入。与独立性想符合，这个要求我觉的有点苛刻，登录是必须依赖的，这个没办法。 4. 【强制】单元测试是可以重复执行的，不能受到外界环境的影响。

说明：单元测试通常会被放到持续集成中，每次有代码 check in 时单元测试都会被执行。如果单测对外部环境（网络、服务、中间件等）有依赖，容易导致持续集成机制的不可用。正例：为了不受外界环境影响，要求设计代码时就把 SUT 的依赖改成注入，在测试时用 spring 这样的 DI 框架注入一个本地（内存）实现或者 Mock 实现 5. 【强制】对于单元测试，要保证测试粒度足够小，有助于精确定位问题。

单测粒度至多是类级别，一般是方法级别。说明：只有测试粒度小才能在出错时尽快定位到出错位置。单测不负责检查跨类或者跨系统的交互逻辑，那是集成测试的领域。 6. 【强制】核心业务、核心应用、核心模块的增量代码确保单元测试通过。

说明：新增代码及时补充单元测试，如果新增代码影响了原有单元测试，请及时修正。 7. 【强制】单元测试代码必须写在如下工程目录： src/test/java，不允许写在业务代码目录下。

说明：源码构建时会跳过此目录，而单元测试框架默认是扫描此目录。 8. 【推荐】单元测试的基本目标：语句覆盖率达到 70%；核心模块的语句覆盖率和分支覆盖率都要达到 100%

说明：在工程规约的应用分层中提到的 DAO 层， Manager 层，可重用度高的 Service，都应该进行单元测试。 9. 【推荐】编写单元测试代码遵守 BCDE 原则，以保证被测试模块的交付质量。

 B： Border，边界值测试，包括循环边界、特殊取值等。循环的边界值，特殊取值，  C： Correct，正确的输入，并得到预期的结果。  D： Design，与设计文档相结合，来编写单元测试。  E： Error，强制错误信息输入（如：非法数据、异常流程、非业务允许输入等），并得检查大S小S：特殊时间点0：00 大Sspecial，23：59分小Ssort 顺序 10. 【推荐】对于数据库相关的查询，更新，删除等操作，不能假设数据库里的数据是存在的，

或者直接操作数据库把数据插入进去，请使用程序插入或者导入数据的方式来准备数据。反例：删除某一行数据的单元测试，在数据库中，先直接手动增加一行作为删除目标，但是这一行新增数据并不符合业务插入规则，导致测试结果异常。

要模拟业务数据的插入才算是自动化测试 11.【推荐】和数据库相关的单元测试，可以设定自动回滚机制，不给数据库造成脏数据。或者

对单元测试产生的数据有明确的前后缀标识。正例：在 RDC 内部单元测试中，使用 RDC_UNIT_TEST_的前缀标识数据。 12.【推荐】对于不可测的代码建议做必要的重构，使代码变得可测

避免为了达到测试要求而书写不规范测试代码。测试先行是一个很好的习惯使用python来达到这个目的吧

Java开发规范​

命名风格:​

命名不符合规范时默认使用主库​

异常规范：​

日志规范：​

代码格式:​

单元测试:​