背景:
工作中接到一个bug排查修复任务,由于自己疏忽导致花了大量时间,记自己这次的翻车记录,大家引以为戒
直接上样例代码
public ResponseUtil test(String titile) {
List<ArticleDto> articleByTitle = articleService.findArticleByTitle(titile);
List<ArticleDto> res = new ArrayList<>();
状态默认都为0
.........................中间省略一大堆业务逻辑代码
for (ArticleDto articleDto : articleByTitle) {
if(articleDto.getTotalNum() > articleDto.getOrderNum()) {
articleDto.setStatus(2);
} else if (articleDto.getTotalNum() == articleDto.getOrderNum() && articleDto.getOrderNum() > 0) {
articleDto.setStatus(1);
}
res.add(articleDto);
}
return ResponseUtil.success(res);
}
异常在于:
status0为不可用,1为已满,2为未满,按理来说订单数量大于0且和总量相等此时状态应为1,但返回的状态却是为0
翻车的过程:
实际工作中,其实这个bug涉及到很多方法和接口,由于该bug也不是我写的,是以前同事遗留的问题,我就开始了“漫长”的代码逻辑阅读,理清到一定程度后,就开始排查,代码逻辑我反复去论证,也尝试了自己觉得可能出现问题的好几种情况,但发现并没有问题,这就很头疼了,我以为是代码的逻辑出现了问题导致我一直反复去推敲业务的逻辑,做了许多的尝试,好了,也许是推敲太久或者其他原因,我觉得一段可疑的逻辑是有问题的,我就很自信的去改了,然后打包到开发环境去进行校验,结果好家伙,直接傻眼了,依旧是状态为0,这就很头疼了,到这其实时间已经花费了一天多了。
然后没办法,只能打日志然后打包打开发环境去日志里面抓,结果发现好家伙,大家应该也猜到了,他压根就没进去判断订单数量和总量相等的if里面,所以压根没运行到里面的逻辑,所以他当然返回初始状态0了,那很明显了,是那个==的问题,其实我当时看代码的时候,我也觉得这个好像怪怪的,但看他是Integer类型我就下意识觉得应该不是,只能说真的大意了,很容易的将Integer和int划了个等号,其实两个还是有很多区别的,这么个简单的bug我竟然花了两天,真的就翻车,虽然可能一方面是工作没多久经验不足,但更多的是自己的思维不会去转变,其实看见他都是0,就应该反应过来他没执行里面的逻辑,就很容易想到是没进判断里面,吃一堑长一智吧。
解决:
其实很简单,把==换成用equals去比较就好了
小知识:
- 包装类比较最好用equals,还能防一手bug
- Integer和int不能划等号,两者还是很大区别的
- int是基本数据类型,默认值为0,Integer是引用数据类型,是包装类,默认值为null。
- ==比较基本数据类型比较的是值,而比较引用数据类型的话比较的是内存地址,所以很容易出现包装类比较明明内容、值一样但比较结果为false,大家一定要引以为戒,引用数据类型还是建议使用equals进行比较。
总结:
- 思维要活跃,要学会转变,不要定性思维去思考问题
- 尽管这次的bug不是我写出来的,但就目前解决这bug的翻车情况不得不说我可能也会犯这样的错误,平时写代码要严谨一些,防止出现一些不必要的bug和犯低级错误
- 吃一堑长一智,自己处于初出茅庐的现状,就要积累经验,错了不可怕,可怕的是你没吸取到教训
文章评论
v