代码规范

• 代码：

• 代码重复

  原因：相同功能代码，抽取独立方法维护，避免重复维护，重视封装，提高可读性，可维护性，扩展性

• java代码强制类型转换

  原因：java核心思想：面向对象，本身推崇强类型环境，针对数据做抽象设计，检查错误，不要当做弱语言使用

• 标识符命名

  原因：驼峰命名，java规范不多说，主要是一些特殊业务场景，英文不够，尽量避免使用中文来凑，即使使用中文也要特殊使用，拼音首字母大写标识，类注释 字段注释标明，尽量做到见名识意，业务类独立，各模块属性，类提供功能给人一目了然之感。

• 模板代码分离

  原因:尽量避免直接在代码层面进行大量字符串拼接，模板代码分离，单独维护，简单易懂，方便后续扩展

• 代码提交

  原因：git提供了多分支共同进行开发能力，但是多人协作开发时，必须保证每次提交前本地代码是可通过编译，才可提交至代码库，合并分支冲突，出现线上本地冲突时需与他人确认后diff差异提交

• controller层代码调用controller中函数

  原因：为保证controller层接口逻辑简单，提高复用性，避免在controller层实现业务逻辑，与前端对接提高复用性，每次接口变更及时更新接口ams

• 方法功能单一

  原因：同上，容易造成controller层承担过多业务逻辑判断，提高维护成本：例如一个相同url同时承担新增编辑功能，这种建议action参数区分为两个接口

• remote中方法不应存在业务逻辑实现，封装思想

  原因：remote，service类本身就应该简单，功能单一，易于维护，方便后续扩展

• 代码-函数不应超过200行：合理优化 可读性 

  原因：这个完全看个人理解，一些大事物逻辑建议尽量拆分，尤其stream流式处理等逻辑，写起来舒服，后面可读性，可维护性极差，对于一些逻辑实现尽量单独抽为独立方法，一个函数所承载功能不应过于复杂

• service层建议不返回null

  原因：当容器返回无数据时，null与空集合虽然都可以，但是为避免上游使用造成空指针异常，so,尽量使用空集合，空对象，所以这块使用rpcResult返回也可避免这种情况产生

• dubbo接口中基本数据类型必须使用包装类型，使用方校验是否为null

  原因：接口极大可能升级，我们现在都是在同一台机器上，但是如果后面布多台服务，编译阶段不能包装不会传null，如果使用小写类型，而传入null,业务代码是没有机会检查，捕获null，且如果因为服务提供方逻辑变更，一些字段意义更改是很容易造成数据异常，最简单的int默认为0，integer可以直接在mapper判null处理，但是int这种不好处理，所以后期尽量使用包装类型

• 严禁dubbo接口中返回枚举

  原因：如果存在枚举，提供方provider更新枚举，会造成consumer序列化失败异常

• dubbo接口建议使用RpcResult包装

  原因：服务提供方无论执行成功与否都应给使用方一个明确的执行结果，如果出现异常因返给使用方异常码及对应异常信息，如果成功，必须保证逻辑结果正确性

• biz层为参数校验异常处理层，此处建议使用异常包装类StatuCodeException及IIIegalArgumentException来抛出业务异常

  原因：一般IIIegalArgumentException主要用来表示参数异常，StatuCodeException主要表示逻辑异常，而我们后续要对这两种异常进行包装，方便后续dubbo，http通过通用方式来处理逻辑运行结果，无需单独处理使用方的异常返回

• 避免修改接口调用方带入参数数据

  原因：这个可选，因为dubbo本身是一种契约协议的制定，在consumer与provider已经对入参数据有制度的前提下再去更改，会导致双方日志不一致，增加问题排查难度，且在多模块部署时，部署期间导致服务不可用，不能兼容上线，建议通过接口升级的方式进行

• 读接口避免同时进行其他操作

  原因：其实这个可以理解为单个方法功能的单一性，在一个业务逻辑中进行多种操作，很容易造成误导性，且若为服务提供方，极易造成使用方理解不一致

• 时间类型转换禁止使用SimpleDateFormat

  原因：线程不安全的类，使用时需要加锁很麻烦，建议使用Local处理时间，java8提供了很多时间类型处理，使用起来方便且会使代码更加优雅

• 日志

• 合理的日志级别

  原因:debug 开发测试阶段，在此阶段可以详细的打印各种信息方便问题排查及测试观测
          info 线上业务日志 记录一些特殊的业务中请求以及相关信息
          warn 线上异常日志，用于记录服务不可控的异常情况，例如：用户请求参数不合法等
          error:线上异常日志，只要出现表明必须人为介入排查，例如服务超时，服务不可用等

• java异常必须以error级别输出，异常对象单独输出

  原因：所有出现异常的地方必须将异常抛出，且输出对应error级别日志说明，异常对象必须单独输出，驿站是异常栈，方便后续问题排查

• 统计日志使用info级别，使用特殊logger名称，清晰表示对于logger输出内容格式要求

• warn及error日志要有对应埋点或异常邮件报警

• 注释要求

  日常开发过程中为了便于开发测试，在许多地方我们会打印业务日志便于分析问题，但是上线前这部分日志是无用且异常消耗性能，占用系统内存的，不利于线上问题分析
  todo日志，上线后必须去除，本身这部分日志是我们开发中一些关键点的注意项，如果大量产生，无用且有误导性
  代码注释：
  每个model中字段必须加/**格式注释，有枚举项必须@see注明枚举类，每个人对一些字段的理解定位都会有偏差，没有详细的注释很难后期维护
  类注释，方法注释，方法体中核心逻辑或有特殊逻辑处理处必须标明此处含义，方便后续问题排查

• 故障要求

• 线上故障处理流程

• 异常解决要求

• 故障技术群内通知

• 以文档形式分析原因时间过程影响

• 故障review，分析产生过程 处理过程，解决方案 原因，后续改善方案

BIZ层参数校验异常模板使用

示例：

@Override
public AssetResponse<List<UserInfoCon>> queryUserInfoConList(UserInfoQuery userInfoQuery) {
return new BizTemplate<AssetResponse<List<UserInfoCon>>>() {
@Override
 protected void checkParams() {
                EAssert.notNull(userInfoQuery, "请求不能为空！！！");
 }
@Override
 protected AssetResponse<List<UserInfoCon>> process() {
 //自己的逻辑实现或与serice层调用实现等
 return response;
 }
        }.execute();
}

此处后续考虑为不影响现有代码层级在StatusCodeException自定义异常类加注解@ResponseStatus，所有BIZ层逻辑异常都需意此类异常抛出，这样客户端直接接收对应异常信息，提高可读性，所有参数校验必须统一置顶

后续希望定义对应的ERRORMSG将我们系统中各类异常及状态码统一维护，另各类冥等模板 异常模板等的使用形成规范，对于redis,es缓存等也应以工具的形式体现，方便管理及使用

• sonar代码检测

• https://edianzu-oss-work-order.oss-cn-beijing.aliyuncs.com/order_attachments/02fde746755ec5c5f533c621a9600575.zip
• 
• 
•