bug的本意是指昆虫、小虫、损坏、缺陷等意思,在互联网时代还有一种引申意义,用来形容某人/物超乎想象的厉害,那简直就是开挂的人生,系统的bug!
一般地,在码农的世界里,bug是在电脑系统或程序代码中隐藏着的一些未被发现的缺陷或问题,可以简称为程序缺陷。从广义上看,还包括软件需要改进的细节、或与需求文档存在差异的功能实现等等。
bug 是如何与程序缺陷联系起来的呢?
Bug的由来
时光回溯到一台计算机可以装满整个房间的时代,大约在1945年9月9日,Grace Hopper发现了Harvard Mark II 计算机的第一个bug。Grace Hopper是数据处理方面的专家,在1952年为UNIVAC开发了第一个编译器,能够把人读得懂的高级语言翻译成计算机能够识别的机器语言。
那一天,Grace Hopper对Harvard Mark II设置好的17000个继电器进行编程后,技术人员正在进行整机运行,它突然停止了工作。于是他们爬上去找原因,发现这台巨大的计算机内部一组继电器的触点之间有一只飞蛾,这显然是由于飞蛾受光和热的吸引,飞到了触点上,然后被高电压击死。死去的飞蛾被夹扁在触点中间,从而“卡”住了机器的运行。
![4a75c108f9ec446fe9d4677f622aaca6.png](https://i-blog.csdnimg.cn/blog_migrate/548772d5d1c51485681f95b6a7a1a397.jpeg)
所以在报告中,Grace Hopper用胶条贴上飞蛾,并用“bug”来表示“一个在电脑程序里的错误”。后来,人们在电脑系统或程序代码中隐藏着的那些未被发现的缺陷或问题,也叫“bug”,同时 把排除程序故障叫DEBUG,这一“称呼”成为计算机领域的专业术语。
BUG和DEBUG的中文译为“缺陷”和“调试”。“缺陷”可能更反映事物的本质,因为“bug”是从外面爬进去的,并非程序本身有问题。而程序本身存在的问题,是程序原来就具有的。
程序代码中Bug的产生原因
一般地,在程序设计中的术语, Bug是在软件运行中因为程序代码本身有错误而造成的功能不正常、体验不佳、数据丢失、非正常中断、死机等现象。
Bug 的产生原因多种多样,千奇百怪,例如:
- 改错了文件
- 改对了文件,但放错了位置,或者根本忘了保存
- 改对了文件但没有重新编译
- 认为把那个条件变量开启/关闭了,但实际上弄反了
- 运行了错误的版本
- 改正了问题,但忘了提交
- 改正了问题,也提交了,但其他代码都依赖于之前有问题的版本
......
软件系统是一个丰富多彩的世界,总有Bug在里面飞来飞去。任何软件在发布时都不可能是绝对的零Bug,因为谁都不敢保证,自己写的代码没有任何问题。
bug的生命周期和分类
实际上, bug的生命周期可能是这样的:
产生-->被发现-->被解决或者变成了另一个bug。
但是从软件工程尤其是QA的角度看,任何一个bug的一般生命周期包括这样几个阶段:
新建-->指派-->已解决-->待验-->关闭
如果等待检验的bug在验证时没有解决好,则需要重新打开bug,开启循环并继续指派。
由于bug众多,我们在fix bug的时候往往本着要事优先的原则,处理那些影响较大的bug,这需要根据bug 的严重程度分类,例如:critical,major,minor,de-effeicency,也就是所谓的P0/P1/P2/P3, 当然粒度也可以分得更细或者粗一点。
根据不同视角,可以对bug有不同的分类,根据bug 所影响的领域分类,QA的测试领域可以参见《程序员眼中的测试》。
另外,bug的数量往往被用来作为衡量软件质量的一个指标。在CMM中规定的软件质量标准如下(Bug个数/千行源代码):
- CMM1级 11.95
- CMM2级 5.52
- CMM3级 2.39
- CMM4级 0.92
- CMM5级 0.32
因此,我们往往会在生产bug 和 debug中徘徊,写代码的时间与排错时间的比例有时会高达2:8。既然debug 是我们工作生涯中不可或缺的组成部分,容易混淆的是,debug 尽管在更多时候是一个过程,但有时候指的是一个程序——debugger。
Debugger是个程序
Debugger为一种调试软件,工程师或程序员可以用来验证算法。在一般的硬件设备上,都有着专门用于debug 的接口,在不太遥远的DOS世界里,一行debug 命令可以起到让操作系统初始化的效果。
在windows平台上,WinDbg是微软发布的一款相当优秀的源码级(source-level)调试工具,可以用于Kernel模式调试和用户模式调试,还可以调试Dump文件。
在Linux平台上,一般使用GDB,又称GNU调试器,是用来帮助调试程序的工具。gdb的主要功能如下:
- 启动程序,可以按照自定义要求随心所欲的运行程序。
- 可让被调试的程序在指定设置的断点处停住。(断点可以是条件表达式)
- 当程序被停住时,可以检查此时程序代码中所发生的事。
- 还可以改变程序代码,修正一个BUG产生的影响从而测试其他BUG。
很多跨平台的编程语言都一般会有各自的Debugger。PHP的调试方法最基本的是echo或者var_dump。还有就是使用zend debug 或者Xdebug的调试插件。
pdb是 The Python Debugger 的缩写,是Python标准库的一个模块。pdb模块规定了一个Python程序交互式源代码调试器,支持在设置断点(包括条件断点),也支持源码级单步调试,支持栈帧监视,支持源代码列出,支持任意栈帧上下文的随机Python代码估值。它还支持事后调试,并且能在程序控制下被调用。
例如:
>>> import pdb>>> import mymodule>>> pdb.run('myfoo.test()')>>>
也可以命令行调用 python -m pdb myfoo.py 。
总之,Debugger是我们在单机debug中非常重要的工具。但是,对于分布式系统而言,这些debugger 都有着很大的局限,虽然也有一些debugger工具,但多是面向特定系统的。
那么分布式系统的debug 主要依赖什么呢?日志。关于日志的重要性,可以参考《全栈必备 Log日志》。
Debug的原则
不论是单机上的应用,还是分布式系统,debug是遵循问题隔离的原则,便于定位问题。
问题隔离可能是所有debug中最强大的核心原则. 问题是否可重现是非常重要的。如果不能重现这个问题的产生方式, 解决起来会变得异常困难。问题隔离使我们拥有了控制变量。
从空间隔离上看,程序代码中具有不同的库或者框架, 并且可以包含许多同事的提交, 其中, 可能有一些已经不再在这个代码库上工作了。问题隔离有助于消除问题的非必要部分, 以便专注于一个解决方案. 问题隔离的目的是弄清楚是发生冲突的根本原因,了解是否存在竞争条件。
从时间隔离上看,避免一次性的大量修改,越少改动代码越好,这样有助于发现问题。连续反馈的一致性结果越多, bug的跟踪就越容易。所以在调试时, 尽量不要安装任何新的软件或组件, 或者引入新的依赖。如果发现每次静态输入却返回了不同的错误, 应该马上提高警惕, 并且全力解决它。
Debug 时的一些雕虫小技
通过二分法去定位问题是Debug的一般方法,即便如此,面对各种不同的编程语言,还有千姿百态的软件系统,我们很难有高效快速的通用方法。
但是, 有一些debug时的关注点,可以看作雕虫小技。
1.环境检查
复现一个Bug,一般从环境检查开始。从底层到应用层逐层检查,要耐心确认。同时,关注帮助文档、手册或数据表,关注工作目录或者运行环境的路径。
2. 日志检查
不要害怕被大量的调试日志,看起来很吓人,但实际上是来帮忙的。大多数时候它会告诉我们真正的问题是什么和在哪里!在25年前,debug C 语言程序的时候,自己好像只能依赖printf来定位问题。
根据日志思考:什么导致了这个错误?错误是如何触发的?...
3. 代码核查
先看看拼写错误吧,typo 或者简单的语法疏忽有时不易发现。有时候括弧或者大括弧的幸运碰撞,有时候context成了content,fetch成了fecth,如果对自己的代码熟视无睹,可以让别人帮着看一眼。
同样,“以终为始”,先检查是否接收了正确的数据类型,一般的防御式编程都可以看到接收的参数或数据。如果接收方合乎预期,跟随调用链的脚步,看调用者的函数,一步一步逼近bug的所在地。
如果定位到了函数,尤其是那些执行的迭代方法(尤其如for、while、do等循环处理),尝试在console上显示一步一步地执行结果。
4. 定向验证
对指定的函数或者逻辑输入固定的数据,或者执行固定的代码来做定向验证,可以是正向的,也可以是逆向的。
如果增加了大量输入还看不到所需输出的话,需要确认一下这些代码真的在执行吗?虽然有了条件语句(如if,switch等),但实际上执行的是在这里么?在条件语句中注入简单的代码,比如打印一个简单的“hello world”,可以帮助您看到程序执行的流程。
当然了,如果有完整一点的单元测试,往往方便的多。
5. 注释代码
如果对于bug发生的逻辑模块位置迟迟不能定位,往往还要回归到通过二分法定位。逐行注释代码的方法可能是可行的,但不是最有效的方法。如果对问题所在没有什么想法的话,这可能是一条必经之路。
6. 手画流程
“好脑子不让烂笔头”,有时候,我们需要一支笔和一张纸,就可以从所有的技术细节中解放出来,就能从视觉上看到事情是如何运作的,把逻辑流程画出来能够帮助我们梳理和定位代码逻辑上的问题。这有点儿像反向工程,尤其对于那些不熟悉的代码,阅读代码并画出流程会提供较大的帮助。
随笔结语
“Zero Bug” 可能是程序员追求的目标,但现实中存在着较大的困难。程序员的日常离不开debug,宽泛一点说是trouble shooting(故障排除)。故障排除在很多时候依赖于经验,反复实践几乎是不二法门,但是,我们可以通过归纳总结自己的经验形成一个“心智模型”,可能是树状的,也可能是金字塔结构,也就是所谓的“套路”。
我们都有一个共同的梦想——成为更棒的程序员,但是如何做?如何学习和精进自己的技术?如何做业务分析和架构设计?如何做技术管理?本书就广大程序员都很关注的问题提供一些思路和方法。
今天我给大家总结出来一份c/c++Linux后台服务器开发架构师成长路线图。需要视频学习的朋友可以后台私信【架构】获取
![087ec5b2f6c1b26e2219a0935fcc653b.png](https://i-blog.csdnimg.cn/blog_migrate/497ed01ebd56024361bb9365482e680a.jpeg)
![ed33507a05d83ace9640734e8ff9dc40.png](https://i-blog.csdnimg.cn/blog_migrate/c729bd2ca86c9da833f49633196a6046.jpeg)