新手上路修复bug翻车记录

---

前言

\qquad 新手上路，工作中接到一个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);
}

---

二、异常问题

\qquad status0为不可用，1为已满，2为未满，按理来说订单数量大于0且和总量相等此时状态应为1，但返回的状态却是为0

---

三、排查（翻车）的过程

\qquad 实际工作中，其实这个bug涉及到很多方法和接口，由于该bug也不是我写的，是以前同事遗留的问题，我就开始了“漫长”的代码逻辑阅读，理清到一定程度后，就开始排查，代码逻辑我反复去论证，也尝试了自己觉得可能出现问题的好几种情况，但发现并没有问题，这就很头疼了，我以为是代码的逻辑出现了问题导致我一直反复去推敲业务的逻辑，做了许多的尝试，好了，也许是推敲太久或者其他原因，我觉得一段可疑的逻辑是有问题的，我就很自信的去改了，然后打包到开发环境去进行校验，结果好家伙，直接傻眼了，依旧是状态为0，这就很头疼了，到这其实时间已经花费了大半天时间了。
\qquad 然后没办法，只能打日志然后打包打开发环境去日志里面抓，结果发现好家伙，大家应该也猜到了，他压根就没进去判断订单数量和总量相等的if里面，所以压根没运行到里面的逻辑，所以他当然返回初始状态0了，那很明显了，是那个==的问题，其实我当时看代码的时候，我也觉得这个好像怪怪的，但看他是Integer类型我就下意识觉得应该不是，只能说真的大意了，很容易的将Integer和int划了个等号，其实两个还是有很多区别的，这么个简单的bug我竟然花了这么长时间，真的就翻车，虽然可能一方面是刚工作经验不足，但更多的是自己的思维不会去转变，其实看见他都是0，就应该反应过来他没执行里面的逻辑，就很容易想到是没进判断里面，而且可以发现自己的基础并不扎实，还需继续努力学习，提高自己的能力，吃一堑长一智吧。

---

四、解决

\qquad 其实很简单，把==换成用equals去比较就好了

---

五、小知识

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

---

总结

• 思维要活跃，要学会转变，不要定性思维去思考问题。
• 尽管这次的bug不是我写出来的，但就目前解决这bug的翻车情况不得不说我可能也会犯这样的错误，平时写代码要严谨一些，防止出现一些不必要的bug和犯低级错误。
• 吃一堑长一智，自己刚初出茅庐，就要学会积累经验，从错误中吸取教训。
• 欢迎大家提出建议以及批评，有任何问题可以私信。