重构实践(2)
2021-10-25 本文已影响0人
墨_0b54
依旧是接口性能优化,查看调用过程后,发现大部分时间耗在服务间调用,其次是一个超多数据的查询。
- 查看接口代码后发现,这是一个分页查询,最后对结果进行数据补充时,在循环中调用其他服务方法和一个结果数据量较大的sql。
- 将循环中的查询提取出来,这一步非常简单,然后把查询结果作为参数传给循环。
-
重构超多数据的查询,意义是判断合同的评审状态,而合同的评审状态由合同中订单的评审状态的聚合结果决定,如下图。
image.png
- 整体来看,这部分逻辑完全可以独立成为一个函数,所以第一步拆分为函数。
- 代码是把第一行就是那个超多数据查询,将合同下所有的订单数据查出来,然后聚合结果,最后拿去判断合同的评审状态。
- 这个查询只有一个订单的评审状态是必要的,其他都是不需要的,所以我只需要把合同下订单的状态单独拿出来就可以了,这里修改后查询速度可以提高150ms左右。
image.png如果所有订单只有一个评审状态,直接判断这个状态;
如果有多个评审状态,有评审通过的订单就是部分通过。
重构后的代码如下,明显比原代码更加清晰,更容易理解。