千云业务代码编写规约
对接实体的命名规范
依赖阿里云的代码规约 https://download.****.net/download/u013642886/12375553
关键步骤需要注解标明
一句话说就是要在写的每一个方法中取其精华去其糟粕。
- 每个方法中尽量将组装部分和执行部分抽离，复杂的执行考虑封装和抽取
- 多关注现在开源项目中的一些代码实现，遇到好的想法多多跟进和学习，慢慢积累经验具备一定的前瞻性和扩展思维。
- 对代码有一定的情怀，喜欢代码不断优化。这个在后续自身提升和代码质量上都有益。
- 后期制定一个基础的节点执行流程，过程建模，也就是流程节点控制，好比一个插线板你要用哪个插口你插上，是洗衣机，或是电冰箱就可以用了。
- 事务尽量使用原子事务，不要挂太多的操作，特别是执行比较慢的操作和查询。For update
- 乐观锁：使用比较好，但是在使用时候问题也多，考虑比较多
- 悲观锁：事务解决使用原子事务，不好将查询和执行放一起操作，在数据库操作做到幂等。
- 不依赖代码的框架来写代码，导致不会关心源代码的流程和实现，多的时间都学习了框架的使用
用户交互建模，数据建模
一句话说明，就是和用户交互的部分和在下层为用户访问提供的数据存储。中间就是业务平台来针对也做统一的入和出。
-
对用户第一交互的部分做交互模型建立。也就是前后端用户交互的字段和实体有统一的处理。
-
和数据库交互的建立数据模型，一般都是一个相关的服务会在一个服务中。这个有争议，比如在service层上提出manager层么？Service中可以依赖service么?等等
-
UC设计规范接口
目的是对业务流程有一个总的交互建模。对系统开发有总体的把控
- 从前到后梳理交互模型。是否和业务平台发生冲突，
- 数据端建立的数据库是否合理【依赖业务熟悉程度】
- 业务平台需要梳理提供通用的接口、
- 在网关融合层进行组装，尽量做跨服务的组装，在有本地库和数据的在本地业务平台处理。
接口文档统一导出
平台出口统一
- 对业务处理的统一平台提供通用接口
- 跨服务查询相关的操作在融合网关进行组装。
- 如果是拿着唯一和索引命中的数据直接绑定子表对应的数据。将所有的数据绑定返回，如果遇到性能瓶颈再做单独的优化处理。
- 不能让接口泛滥，尤其是提供新的接口和服务声明时候看看是否是通用接口，如果是需要组长自己来评估。下边是同样一个查询被写了4次，在优化后一个业务平台从将近200个接口梳理后剩余的接口数为21个左右
日志打印规范
-
在业务日志打印使用JSON.toJSONString（obj）时候注意get实现不能抛出异常的情况下使用，这里的ecCode为空时候序列化报错导致业务停滞，所以在有重写get的地方尽量使用或者不要以get开头定义方法或者重写toString
-
在打印业务中的跟踪时候，使用线程时候在定义线程时候需要使用当前线程包装后的线程池进行使用。避免多线程的调用不能跟踪上对应的调用链。
原生功能和框架功能共存
- Api声明尽量不要使用Lombok。
- Validate统一使用hibernateValidate,依赖JSR303的规范