【bug】垃圾代码,以及优化问题

1、类型错误

【bug】垃圾代码,以及优化问题_第1张图片

2、非空判断位置错误

【bug】垃圾代码,以及优化问题_第2张图片

3、同类事物失效

【bug】垃圾代码,以及优化问题_第3张图片

处理方式二选一:

【bug】垃圾代码,以及优化问题_第4张图片

【bug】垃圾代码,以及优化问题_第5张图片

4、逻辑错误

【bug】垃圾代码,以及优化问题_第6张图片

既然是第一次循环遍历完成就要break结束循环,为何不直接取第一个元素?

5、代码优化相关问题:

a、验证

【bug】垃圾代码,以及优化问题_第7张图片

b、非空校验

【bug】垃圾代码,以及优化问题_第8张图片

c、复杂度

【bug】垃圾代码,以及优化问题_第9张图片

【bug】垃圾代码,以及优化问题_第10张图片

关于嵌套查询的优化:可以将要嵌套的集合转成一个map集合,在循环第一层时,通过map集合获取对应数据就ok了

d、性能

【bug】垃圾代码,以及优化问题_第11张图片

【bug】垃圾代码,以及优化问题_第12张图片

像这种循环去掉用其他服务的接口、以及循环去操作数据库是非常耗性能的,

图1优化,可以新增接口通过idList集合去查询出对应数据,在将获取到的数据转为map集合,在外层循环时只需通过map.get()方式获取数据,图2优化方案也是同理

【bug】垃圾代码,以及优化问题_第13张图片

对比:

【bug】垃圾代码,以及优化问题_第14张图片

【bug】垃圾代码,以及优化问题_第15张图片

【bug】垃圾代码,以及优化问题_第16张图片

在做查询时,去计算数据库每行数据的话,这样会导致索引失效,只能通过计算自己的参数,不能计算数据的某个字段

e、服务间关联调用的Client接口返回结果必须使用Result包装结果对象,避免无法进行结果集映射,因为当被调用服务发生异常时,异常会被自定义的异常拦截处理器CustomExceptionHandler捕获处理,并返回Result包装的结果集对象。

【bug】垃圾代码,以及优化问题_第17张图片

【bug】垃圾代码,以及优化问题_第18张图片

f、在调用其它服务、其它业务系统服务或第三方服务时,不允许直接获取返回结果Result.data,必须先判断返回结果是否成功,再进行下一步业务处理,否则容易引发NullPointerException;在返回失败的情况下,要记录返回失败的异常信息,便于问题的查找定位,再根据业务需要判断是否需要继续进行当前业务流程。

【bug】垃圾代码,以及优化问题_第19张图片

g、当发生异常时,在catch代码块中不允许使用e.printStackTrace()来打印异常栈信息,因为e.printStackTrace()打印的异常信息只会打印到控制台,不会记录到日志文件中。除业务不关心异常信息外,其它任何情况均要采用log.error(String var1, Throwable var2)的方式打印完成异常栈信息,根据业务需要可以适当降低日志打印级别,在出现异常时有助于定位问题发生的具体代码行数及具体原因。

【bug】垃圾代码,以及优化问题_第20张图片

【bug】垃圾代码,以及优化问题_第21张图片

你可能感兴趣的:(Java)