修复bug翻车记录

背景

  工作中接到一个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去比较就好了

小知识:

  1. 包装类比较最好用equals,还能防一手bug
  2. Integer和int不能划等号,两者还是很大区别的
  3. int是基本数据类型,默认值为0,Integer是引用数据类型,是包装类,默认值为null。
  4. ==比较基本数据类型比较的是值,而比较引用数据类型的话比较的是内存地址,所以很容易出现包装类比较明明内容、值一样但比较结果为false,大家一定要引以为戒,引用数据类型还是建议使用equals进行比较。

总结:

  • 思维要活跃,要学会转变,不要定性思维去思考问题
  • 尽管这次的bug不是我写出来的,但就目前解决这bug的翻车情况不得不说我可能也会犯这样的错误,平时写代码要严谨一些,防止出现一些不必要的bug和犯低级错误
  • 吃一堑长一智,自己处于初出茅庐的现状,就要积累经验,错了不可怕,可怕的是你没吸取到教训
点赞
  1. 鸟人金说道:
    Firefox Windows 10
    v

发表回复

电子邮件地址不会被公开。必填项已用 * 标注