一转眼，半年过去了，半年前，还是一个连http请求，handler怎么用都不太会的标准菜鸟（当然，现在也是菜鸟）。
才来公司的时候，老大交给我一个老项目让我改bug。那一改就是3个月，三个月的时间，边开发新功能，变修复原有bug。说实话，一来就是一个class有上千行代码，一个包几十个类的项目，看着都头疼。连出现bug的位置都要找半天。具体哪些bug，已经不太记得了，只是把一些经验性的东西，总结出来分享。
改bug的几个阶段（场景），我来聊聊吧（也是自己改bug的阶段，每个阶段改的方式，方向可能都有 不同）：
第一个阶段：最基础的阶段，看日志。这种，就是那种错误明显的，直接点日志，跳到对应位置那种。比如空指针，改的方法就是看哪个值为空了，再看看这个类，什么时候赋值了呀什么的。修改难度，应该算最小的。
第二个阶段（场景）：也有日志，但是，你点击日志跳到对应位置，发现（卧槽，这代码不是我写的，是Android自己写的），然后，就纠结，这tm什么问题呀，都不是我写的，怎么搞呀。经过一番思来想去之后，决定，百度一下吧，把这段错误信息放到网上一查，诶，有结果了。然后按照网上说的那样，改改改，行了。
第三个阶段（场景）：还是有日志，但是，没有可以点击的日志，全是一啪啦英文，靠，这什么鬼，完全没思路呀。然后，又是纠结，沉思，最后实在没办法了，读日志吧，一句句读，最后终于读懂什么意思了，然后，又把错误内容加上自己的理解百度一下，再不行就在it群里面问，最后，也解决了。
第四个阶段（场景）：我×，没有报错，没有蹦，没有日志，这tm怎么就跟我想的不一样呀。这个时候，只能去读代码了，看自己这个模块的代码是哪些，哪一步是应该显示我那个正确结果的，然后，一步一步往上推，看数据从哪里来，走了哪些步奏，看view哪里创建，又在哪里显示。然后打断点，单步调试，最后发现，原来是这一步没有传值（或者取值错了什么的）。
第五个阶段（场景）：这类场景比较复杂了，这类场景就是，我一个类很大（几千行代码那种），然后，引用了10几个类（可能更多）。在这个类里面某句话出了问题，或是怎么样。这种情况千万不要，一上去，就改，因为，很有可能（反正，我是百分之百）会这个bug改了，又出现新的bug了。这种情况最正确的做法是，先把这部分内容读懂，弄明白是干什么的，最好是能重构一下。让整体结构和思路变清晰，然后，再去找问题的根源。
第六个阶段（我现在的阶段）：基本问题，秒改，复杂问题，先重构再改。
ok，最后总结一些经验性的话吧，遇到问题的几个处理步奏：1找现场，还原现场。2向上溯源，向下延伸。3累积
第一点：找现场，还原现场。说的是。先找到这个问题，这个场景，出现的地方（包，类，代码块），其实就和警察办案一样，先到案发现场找线索，因为案发之后一定会留下蛛丝马迹。然后，就是还原现场，就是把这个问题复现，就想警察会还原案发现场一样，帮助推理，和理清线索。
第二点：向上溯源，向下延伸：找到现场之后，分析这个问题，数据源是哪里，传来的数据是什么，向下延伸，是指，考虑这个对象，对他后续的对象（比如谁引用了他）有什么影响。简单来说，就是。向上溯源，是为了解决当前这个问题，向下延伸，是规避制造新的bug。也可以换一种说法，叫依赖。相信搞java的同学对这个词理解应该会很深。
第三点：累积，其实就是累积经验，我现在之所以能秒改一些问题，就是因为，曾经一天要改10几个bug，改了3个月。见都见了很多bug了，看着就不陌生了，就好办了。所以，遇到bug，不要着急，改一个，就进步一点。
还有千万不要以为改bug，不如写项目。这么说吧，我改的bug，比我写的项目还多（真是多亏了之前的哥们，给我留了那么多bug，别让我遇到，遇到打死）。改着改着，就发现，这样写容易产生bug，该怎样怎样写，才能避免bug。比如一个eventbus，容易忘记反注册。后来，就写了一个生命周期框架，让activity自己去管理，我不管了。比如一些规则验证不写容易出现奇葩bug，然后就写了一个规则验证的api，用着很爽。也是多亏了之前累积的bug，这次我写的项目，大家都加班了，就我几乎没加班，然后写出来之后，基本上没什么bug，测试也通过主流程，只是改一些小细节了。所以才有这时间写这篇文章。
最后分享一点，作为一个程序员（虽然我现在，已经在渐渐负责框架，架构方面的设计），编码才是硬本事，写出来的代码bug越少，代码越少，性能越高，扩展性越好才是能证明你的水平。别一来就是xx模式，xx架构，xx框架的。
网友评论