每一次的review会有很多问题暴露出来,争取每次消化两个点。真正的理解review 时讨论的东西。
今天在review的时候,大家对不同的问题提出了很多建议的地方,也有不同的解决方案,有设计的不合理的,有代码写法需要优化的等等,但是在讨论的时候有个需要注意的点:我们不管讨论什么,一直在说的是软件这个行业里的事,每个行业有它独特的发展方向,所以我们在讨论各种问题的时候,记得不能脱离软件行业里写代码的一些思维方向性的东西,比如面向对象思维,模块化思维,微服务化思维等等,这些大的方向不能违背,我们很容易掉进为了解决一个具体的代码问题提出的违背大方向思维的解决方案,虽然技术上的限制能够通过,但从软件思维角度来讲并不是一个好东西。
1 写好注释,暂且从不同地方的注释维度去理解[方法注释,参数注释,类注释等]
a 注释的有效性。这种在写参数注释的时候比较明显,现有代码里,很多是对参数从英文到中文的翻译过程,仔细回想,直接的翻
译过程对注释本身来讲没有意义。如果我们去对接这个注释,看到的都是字段的翻译中文,写代码同样没用。反过来,如果让我
对接一个接口参数,我看到注释后,需要知道哪些信息?答案是这个字段对应业务上面的一些描述。比如给一个XXId,我需要知道
的是这个id 的范围,有哪些校验逻辑,如果该参数出错我需要给接口什么样的提示等限制条件。尽可能的多思考一些对应的业务
意义,对这个字段的翻译反而是比较小的工作量。思考完之后字段的使用就会清楚很多,别人看见字段也才能通过注释传达有效
信息。
b 注释的逻辑表达粒度问题。比如一个方法的功能是提现,该方法的描述不应该只有提现两个字,提现只能表达这个方法做了什么
事,但是方法内部逻辑有分几步,需要大致写出来。有两个好处,一个是通过写逻辑步骤整体代码逻辑的梳理会更加清楚,逻辑
上不会出现太过偏离的东西。另一个是给别人看的时候会更加明确,不然告诉别人是提现,但没有逻辑描述基本不能做什么具体
的事情。
c 类注释的使用。我们一般类上的注释就是对该类的模块内容有大致说一下,但是具体的东西是在方法上讲的更多,所以类上的注
释可以附带一些对应的文档地址类的东西,比如设计文档wiki等。
2 事务写法。
a 概念:更新数据库中各数据项的一个程序执行单元。
b 存在理由: 解决数据的安全操作,控制数据的安全访问[eg:转账的时候,A账户钱已扣,B账户还未到账时,异常导致转账中断,则需要A 撤回转账以保障数据正确性]
c 事务特性【ACID】
1 原子性{atomicity}:对数据的修改,要么全部执行,要不全不执行。
2 一致性{consistency}:执行前后数据要求一致,数据完整性的要求。[eg:转账前后总金额不变]
3 隔离性{ioslation}: 事务之间不要相互影响。
4 持久性{durability}: 事务提交需要永久保存到DB中。
d 事务隔离级别:低到高分别为Read uncommitted 、Read committed 、Repeatable read 、Serializable
https://www.cnblogs.com/ubuntu1/p/8999403.html
e java事务种类:JDBC 事务,JTA(java transaction API),容器事务。
具体的三种事务的介绍:https://blog.csdn.net/weixin_37934748/article/details/82774230
f 为什么?@Transactional只能被应用到public方法上,对于其它非public的方法,如果标记了@Transactional也不会报错,但方
法没有事务功能。[结合注解/aop原理思考]
g 默认情况下,一个有事务的方法, 遇到RuntimeException 时会回滚,要想所有异常都回滚,要加上
@Transactional(rollbackFor={Exception.class,其它异常})
h 事务套事务会怎么样【外层失败了,里层会怎样?里层失败了,外层会怎样?通过事务的传播级别行为来理解】
接口TransactionDefinition [建议看看源码,虽然英文看不懂]里定义了事务的传播行为和隔离级别,
常用的三个传播行为:
1 PROPAGATION_REQUIRED,spring 默认的级别,存在一个事务,则支持当前事务。如果没有事务则开启一个新的事务。
eg: A 方法调用B 方法,就只会在一个事务里,所以如果A或者B 方法失败了,AB两个方法都会回滚。
2 PROPAGATION_REQUIRES_NEW,总是开启一个新的事务,一个事务已经存在,则将这个存在的事务挂起
eg: AB 两个事务互补影响,各自失败的话各自回滚。
3 PROPAGATION_NESTED,嵌套的意思。
eg: 如果 B 方法失败了,对A 方法无关紧要,B 方法自己回滚即可,但如果A 方式失败了,则AB 都需要回滚,此时就可以
用到嵌套的方式处理。
i 写事务注意点:1 事务尽可能小一些,避免使用长事务 2 尽量避免调用第三方的接口时使用事务。