|
BUG是什么，顾名思义，就是虫子，这种东西当然恶心，程序好比程序员的一日三餐，如果里面混入了BUG，就如同在饭菜中混入了苍蝇一般，于是，程序员一怒之下把苍蝇夹了出来，然后继续吃饭。 如果说需求是主线任务，那解BUG就是程序员每天都要刷的日常任务，每个程序员都会有一些自己独特的解BUG思路，我们今天就来说说一些惯用路数。 一个比较常见的场景，产品经理提了一些需求让程序员做，程序员做完了后交给产品体验，产品用着用着发现有地方不对劲，或者是逻辑上或者是视觉上，于是拉着程序员的小手说：“果果，我体验了下挺好的，就是这里有点小BUG，你能帮人家解决下吗？”（纯YY，如有雷同，纯属巧合）。 大多数情况下，程序员立刻就会被BUG吸引，“哪里有问题，怎么复现？”，于是产品经理一顿啪啪啪操作，程序员聚精会神的看。这个时候程序员脑中其实是在飞速定位问题，无数行的代码在脑中哗哗哗的滑过，毕竟，要解决一个BUG把所有代码看一遍是不可能的，这个时候就是要通过观察复现的操作来缩小BUG可能出现的代码区间，当然，这个区间可能也很大。 接下来，程序员会说：“好的，看到了，我调一下，看看怎么回事”。“调”是调试的意思，那什么是调试呢？调试简单说就是借助一些开发工具帮助定位问题。程序开发时都有一些开发环境，同时也会配有调试工具，最常见的调试方法就是断点，程序代码实现的功能虽然千差万别，但是归根结底就是一堆变量在那算来算去，传来传去，如果有BUG，那就说明有变量的计算或传递不符合预期，调试时使用断点就能让程序运行到指定的位置时停下来，冻结现场，这时程序员就能够查看此时的各种变量具体是什么，是按照怎样的逻辑传递到这里的。所以之前通过观察复现路径，能够帮助程序员初步判断BUG可能出现的地点，然后在自己怀疑的地方打上断点，静态观察分析，进一步缩小怀疑范围，然后再次断点分析，直至最终找到BUG藏身之处。 虽然断点调试功能很强大，但是无法解决所有问题，因为程序的运行往往存在多个进程，多个线程，随着CPU的调度，它们交替运行，如果一个BUG和它们扯上关系，那断点调试就显得不可靠了，因为CPU调度的顺序不同，最终运算的结果就会不同，即使通过断点冻结其中一个，但是其他的进程和线程还在运行，观察的结果仍然不可信，此时就需要借助打LOG的方式（LOG是谁？），其实就是输出日志，程序员在自己怀疑的点写上一些日志代码，当程序运行到指定位置时通过日志输出一些当前变量的值，这样就能够观察程序自然运行时变量是怎样改变的，以及通过日志输出的顺序来判断进程和线程的执行顺序。这种类型的BUG往往是随机出现，断点的时候不一定出现，可能调了半天白调了，如果正好在断点的时候出现了只能说是运气好，但大多数情况是断点破坏了真实的进程和线程的调度顺序，导致一断点程序就正常了，怎么调不到错误点上。但是LOG就不一样，它是程序运行前世今生的证据，一旦复现问题，就可以反查LOG进行分析。 还有一些BUG是不容易发现的，比如产品经理可能会在后台看到各种程序异常退出的吐槽，而程序员在后台的异常上报中看到的各种奇怪的crash点，它可能出现在程序的任何一个地方。这种BUG的特征就比较像内存泄漏，就是代码写的有问题，把资源一直持有不放，结果资源越持有越多，系统可分配的内存越来越少，最后，哪个倒霉蛋压上了最后一根稻草，哪怕不是它的问题，最后也会挂在它那。这时程序员往往会拿出内存分析工具，一顿乱七八糟的操作后把内存数据导出来，看看有哪些应该释放的资源没有释放，比如很久之前看了一张图片，但是现在早就离开那个场景了，但是内存中还保留着那张图片的资源，那么这就成为了可怀疑的点了。 程序员之间互相争着推BUG的时候，调试就成为了强有力终结性打击武器，看到调试结果，任何辩解都是苍白无力的，正所谓一言不合就调试。 |
|
|
