编程规范

1.代码提交pr前，需要对所有涉及的修改进行格式化

2.去掉所有多余的import

3.http接口必须有@RequestLog注解

4.对简单的数据校验，使用注解实现

5.业务数据校验，只校验一次，多余的校验需要删除

6.用MAssert代替checkArgument校验

7.接入外部接口，需要充分利用开关，降低对外部接口的依赖

8.提供接口，需要了解调用方的调用场景，调用次数，影响功能

9.数据库访问逻辑和业务逻辑分离，这样可以分别做业务和数据库的单测

10.web层禁止存放service和manager，mapper，并且controller禁止写业务逻辑

11.service层 实现业务逻辑，严禁写数据访问的代码，如果业务逻辑较长，需要按照功能拆分子函数，

包括参数校验，参数组装，参数转化；如果需要复用逻辑，需要在接口中声明，提供其他的service进行复用

12.manager层 不要有业务逻辑代码，只负责mapper的实现和事务处理

13.接口声明在api层，接口实现在server层，不要把接口实现写到web层

14.不要在程序中出现魔法数，需要使用常量或者枚举，方便快速理解业务含义

15.所有写数据库，云搜，缓存的接口方法，必须考虑并发 （分布式锁，sql处理)

16.页面对象使用vo，业务层需要统一转化成bo，如果涉及外部接口调用，统一使用dto

17. 新增或者修改接口，必须保证服务化文档的正确性，保证提交pr前，文档编译通过

18.如果需要抛出异常到页面，需要检查错误提示信息是否合适，必要时联系PM

19.所有外部接口调用必须有入参日志和出参日志，写到proxy

20.查询或者写接口，如果调用方调用频繁，需要提供批量操作方法

21.避免if-else 大量嵌套，异常分支直接return或者抛出异常，让代码层次变得清晰，可读性，可维护性高

22. 提pr前，开发的代码必须通过单测覆盖所有分支，执行通过

23.接口方法命名，需要尽量简短清晰，明确具体，不用过长，范围过大或者模糊的命名

24.如果有了@slf4j注解，就不需要再重复使用LOGGER，避免冗余代码的出现

25.多使用Objects.nonNull和CollectionUtils 等现成的工具方法，避免自己重复造轮子，还容易出错

26.service 内方法不要过长，需要根据业务，重要性，调用频率等维度拆分，写接口和查询接口方法必须拆开

严禁混在一个service中，建议单个方法总行数不要超过50行。

27.避免不必要的外部接口调用，调用频繁需要使用批量接口

28.新增或者更新接口方法，必须考虑调用失败的补偿机制，结合业务，尽量做到无需人工介入即可恢复数据。

29.禁止循环中发送消息

30.系统中的现有代码，如果复制来用，需要多思考针对业务判断是否需要优化，禁止无脑复制。

31.复杂的业务代码逻辑，需要有明确注释

32.如果是串行执行，调用很多外部接口或者查询不同数据表，相互无依赖，需要考虑并行化提升性能

33. POJO类中布尔类型的变量，都不要加is前缀，否则部分框架解析会引起序列化错误。

反例：private boolean isDeleted = true; 定义为基本数据类型Boolean isDeleted的属性，它的方法也是isDeleted()，RPC框架在反向解析的时候，

“误以为”对应的属性名称是 deleted，导致属性获取不到，进而抛出异常。

34. 不用使用一个常量类维护所有常量，要按照常量功能进行归类，分开维护，必要时需要使用枚举

35.提供给外部的接口，如果入参是list，需要明确好入参个数，并且观察性能，禁止不设个数上限的入参

36.所有调用外部接口或者查询各种数据源获取的结果，使用前必须判断非空，避免空指针异常，如果按照下标操作值，

需要考虑边界值等情况

37.所有的POJO类属性必须使用包装数据类型，RPC方法返回值和参数必须使用包装数据类型，

建议局部变量使用基本数据类型

38.序列化类新增属性时，不要修改serialVersionUID字段，避免反序列化失败

39.构造方法里面禁止加入任何业务逻辑，如果有初始化逻辑，请放在init方法中

40.POJO 类必须写 toString 方法。使用 IDE 中的工具:source> generate toString时，如果继承了另一个 POJO 类，注意在前面加一下 super.toString。在方法执行抛出异常时，可以直接调用 POJO 的 toString()方法打印其属性值，便于排查问题。

41. 如果无需暴露给外面使用的方法，要使用private修饰；如果与子类共享，必须是protected

42.小心使用Object的clone方法来copy对象，默认为浅拷贝，如果要实现深拷贝需要重写clone方法

43.如果参数中需要使用可变参数，必须放置在参数列表的最后。

44. 尽量避免使用过时的类和方法

45.ArrayList的subList结果不可强转成ArrayList，否则会抛出ClassCastException异常

46.使用集合转数组的方法，必须使用集合的toArray(T[] array)，传入的是类型完全一样的数组，大小就是list.size()。

47.线程池不允许使用Executors去创建，而是通过ThreadPoolExecutor的方式，这样的处理方式更加明确线程池的运行规则，规避资源耗尽的风险。

48.SimpleDateFormat 是线程不安全的类，一般不要定义为static变量，如果定义为static，必须加锁，或者使用DateUtils工具类

49.switch块内，每个 case 要么通过 break/return 等来终止，要么注释说明程序将继续执行到哪一个 case 为止;在一个 switch 块内，都必须包含一个 default 语句并且 放在最后，即使空代码。 


50.在 if/else/for/while/do 语句中必须使用大括号。即使只有一行代码，避免采用 单行的编码方式:if (condition) statements;


51.try-catch覆盖的代码块 需要尽可能小，不覆盖不会出错的代码,对于容易出错的代码,需要尽可能细分异常类型。

52.对 trace/debug/info 级别的日志输出，必须使用条件输出形式或者使用占位符的方式，如果使用字符串拼接，会浪费系统资源

53.涉及到敏感信息的字段，需要注意脱敏

54.涉及到金额的字段，需要使用BigDecimal，并且要注意精度

55.如果方法入参个数超过3个，需要把参数封装到对象中，避免函数参数列表过长

56.出错的异常处理，严禁使用e.printTrace()这种无任何意义的代码，打印错误日志要清晰准确，对结果码和结果信息处理，需要和其他对接的研发RD，

前端FE和产品PM做好充分沟通，如果沟通不准确，不及时，造成的一切后果由RD负责。

57. 尽量避免使用join查询，在业务层，单表查询出数据后，作为条件给下一个单表查询。

58.如果只有是和否的选项，一般字段设计使用Boolean，对应数据库字段类型为tinyint(1)，而不是Short类型，避免错误的数值进入

59.提供的RPC接口DTO不要直接使用枚举类型

60. 对于数据库非空的字段，程序中操作该字段的写方法，必须设置默认值，防止更新数据库产生null的异常

61.对外提供的枚举等基础类，尽量不要放在自己服务的内部commons包，减少依赖

62.新加入的service和controller，需要增加配置到SERVICE.DESCRIPTION.xml中，并且保证编译得分pass

63.枚举值新加字段，需要放到最后，而不是在中间增加，会导致反序列化错位的问题。

64. 使用手机号加密，需要注意多线程共享对象，导致某个手机号加密2次，造成查询出错的问题。

65. 对于某个功能的字段数据转换，可以放在bo-->vo进行，增强bo可复用性。

66. Thrift接口，方法声明，绝对不能使用泛型，会产生错误。如下图