面对Bug程序员能做点什么

简介: 我们程序不可避免的会出现bug,那么我们能做哪些事情,尽可能减少bug的产生

Bug之殇
所谓bug,就是程序当中的出现的缺陷或者错误,他们会导致程序出现一些不合预期的结果,甚至会导致崩溃。

1947年9月9日下午3点45分,格蕾丝·霍珀在她的记录本上记下了史上第一个计算机Bug——在Harvard Mark II计算机里找到的一只飞蛾,她把飞蛾贴在日记本上,并写道”First actual case of bug being found”。
image.png
历史上有一些后果非常严重的Bug。

宰赫兰导弹事件

1991 年 2 月第一次海湾战争期间,部署在沙特宰赫兰的美国爱国者导弹系统未能成功追踪和拦截来袭的伊拉克飞毛腿导弹。结果飞毛腿导弹击中美国军营。当场炸死28个美国士兵,炸伤100多人,造成美军海湾战争中唯一一次伤亡超过百人的损失。

时间计算不精确以及计算机算术错误导致了系统故障。从技术角度来讲,这是一个小的截断误差。当时,负责防卫该基地的爱国者反导弹系统已经连续工作了100个小时,每工作一个小时,系统内的时钟会有一个微小的毫秒级延迟,这就是这个失效悲剧的根源。爱国者反导弹系统的时钟寄存器设计为24位,因而时间的精度也只限于24位的精度。在长时间的工作后,这个微小的精度误差被渐渐放大。在工作了100小时后,系统时间的延迟是三分之一秒。雷达在空中发现了导弹,但是由于时钟误差没有能够准确地跟踪它,因此基地的反导弹并没有发射。

英特尔奔腾处理器

1994 年,英特尔的奔腾微处理器芯片的浮点计算单元出现了一个 Bug。对于精确计算,处理器将返回不正确的十进制值。当时有大概 500 万个缺陷芯片在流通,英特尔最终决定为所有投诉的人更换芯片。这之后,英特尔把他们的故障处理器做成了钥匙链。预计损失为4.75 亿美元

在奔腾浮点单元的分频器中有一个有缺陷的除法表,在约一千个条目中丢失了五条纪录。然而,这个错误在 90 亿随机浮点小数的除法中仅可能出现一次。例如,将 4195835.0 除以 3145727.0 得出 1.333739068902037589,而不是 1.333820449136241002,有 0.006% 的误差。

阿丽亚娜5型运载火箭

1996年6月4日,阿丽亚娜5型运载火箭的首次发射点火后,火箭开始偏离路线,最终被逼引爆自毁,整个过程只有短短30秒。

阿丽亚娜5型运载火箭基于前一代4型火箭开发。在4型火箭系统中,对一个水平速率的测量值使用了16位的变量及内存,因为在4型火箭系统中反复验证过,这一值不会超过16位的变量,而5型火箭的开发人员简单复制了这部分程序,而没有对新火箭进行数值的验证,结果发生了致命的数值溢出。发射后这个64位带小数点的变量被转换成16位不带小数点的变量,引发了一系列的错误,从而影响了火箭上所有的计算机和硬件,瘫痪了整个系统,因而不得不选择自毁,因此损失了3.7 亿美元。

Bug的分类与应对

美国计算机科学家、图灵奖获得者詹姆斯·尼古拉·格雷(Jim Gray),在他的著名的论文中首次提出了程序bug的类型,根据bug的出现情(如能否复现)况分成如玻尔bug(Bohrbug)、 海森堡bug(Heisenbugs)等

而然我还是希望能够从bug成因的角度进行分类,这样才能够好的避免bug,以下是大胡子的分类法以及应对方案:

算法Bug

成因:由于程序员对算法实现错误而产生的bug,如奔腾处理器的长除法问题。

应对方案:单元测试

算法Bug相对独立,可以通过对算法模块本身的充分测试来发现问题。这些测试通常都是比较容易自动化的,即通过程序定制输入,判断是否出能得到预期 的输出,来保证正确性。

回归Bug

成因:由于产品功能调整,版本更新,出现了原有的代码没有考虑到的情况,导致出现问题,阿丽亚娜5型运载火箭就属于这个问题。

应对方案: 回归测试

通过重新运行原有功能的测试case,保证以前的功能符合预期。

场景bug

成因:并非单个功能点有问题,而是由于使用的场景和用户的预期不符,导致输入错误,或者使用流程出现了没有考虑到的情况。比如支付宝的找回密码问题。这类问题通常并非全是程序员的原因,产品经理也对此负有责任。

应对方案:测试服务器/测试环境

复杂的bug很难通过简单的测试发现,需要一定的用户使用量,通常公司会采用一个测试环境邀请一批用户进行试用,从而尽可能的发现bug。比如著名的游戏公司暴雪,在更新他们所有的游戏版本之前,会先更新到测试服务器(即PTR服务器),这个服务器是公开的,通过这样的方式来收集用户的反馈。这已经是一个非常成熟的过程。

累计bug

成因:冰冻三尺非一日之寒,此类bug通常由于微小的错误累计而成,短时间内不易察觉,然而程序长时间运行后,可能会引起严重的后果,如:宰赫兰导弹事件中的bug,或者内存泄露,性能问题等

应对方案:测试服务器/压力测试

测试服务器是一个不错的方案,你可以在这里长期运行你的程序,从而发现问题。压力测试可以更有针对性的判断你的程序在一定的工作量情况下是否会产生问题。

以上,便是我对于程序bug的一些思考,希望对大家有所帮助。

目录
打赏
0
0
0
0
1
分享
相关文章
程序员为何需要反复修改Bug?探寻代码编写中的挑战与现实
作为开发者,我们在日常开发过程中,往往会遇到反复修改bug的情况,而且不能一次性把代码写的完美无瑕,其实开发项目是一项复杂而富有挑战性的任务,即使经验丰富的程序员也难以在一次性编写完美无瑕地完成代码,我个人觉得一次性写好代码是不可能完成的事情。虽然在设计之初已经尽力思考全面,并在实际操作中力求精确,但程序员仍然需要花费大量时间和精力来调试和修复Bug。那么本文就来分享程序员需要反复修改Bug的原因,以及在开发中所面临的复杂性与挑战。
280 1
程序员为何需要反复修改Bug?探寻代码编写中的挑战与现实
你是一名努力工作的程序员,还是懒惰的程序员?
当人们在进行一项体力工作时,你很容易评估他们工作的努力程度。你可以看到他们的身体动作,看他们流了多少汗水。也可以去看他们的工作成果:砖墙越砌越高,地上的洞越来越大。对努力工作的认可和奖励是人类一个非常基本的本能,这也是为什么我们对耐力运动如此着迷的原因之一。然而,在管理一些技术创造型的员工时,这种对体力上的努力工作的本能欣赏却变成了一个问题。高效率的知识工作者通常看起来并不像是在努力工作。
142 0
你是一名努力工作的程序员,还是懒惰的程序员?
如果你有拖延症,程序员不如试试这个技巧提升效率?
  要吃掉一头大象,每次吃一口。   ——克雷顿·艾布拉姆斯(Creighton Abrams)   造成拖延的首要原因之一,同时也是造成生产力低下的祸根,就是总是在感慨一个问题:好忙啊,问题好大啊……实际上,你并没有真正试着去解决问题。当我们从任务的全貌来审视任务的时候,它们看起来比真实情况都要大,并且更吓人。   在本文中,我会谈及一个能够帮助你克服拖延的提高生产力的窍门:分解任务。通过将大任务分解为小任务,你会发现自己更有动力去完成它们,也更加稳妥地向着目标前进。
190 0
如果当初学习编程时能有人给我这些忠告该多好
Cecily Carver 是多伦多的一位程序媛,和 Jennie Faber 一起创办了一个游戏制作工作室。她喜欢歌剧、舞蹈和弹钢琴。Cecily 在这篇文章分享她在编程道路上的所感所想,给出很多值得思考的编程箴言以及一些思想误区,比如在你学习编程之前思考一下你的目标、编程不是什么神秘的东西、坚持比方法更重要等,可以让我们在编程路上少走一些弯路,从而有更多的时间学习技术让自己变的越来越强大。
253 0
影响程序员生涯的三个错误观念,你千万不要犯!
程序员在社会上,到底是怎样一个生活群体?是否能找到自己方向?其实,路一直都在那里,只是你看不到而已! 当初的你,可能一直被一些技术牵着鼻子走,并不是自己在做着自己想做的,而是被技术推到了现在这样子。
1267 0
当程序员遇见茶道,这场景你都想象不到!
这是一个茶友与一个技术型的程序猿兼茶盲一起喝茶…… 场景:办公室。装修完毕,茶具一一到位。拉开架势、准备沏茶。程序猿闻声而至,坐于茶桌前。 程序猿:矮油,茶台怎么那么破旧,呐,你看看,这里还有几个破洞。
1195 0
程序员的那些反模式
  有鸡汤就有反鸡汤,有模式就有反模式。   今天,我们来谈一谈程序员的行为中的那些反模式,涉及程序员的日常工作和学习的各个方面。   这些反行为模式,并不针对某些特定的个人。如果你不幸中招,千万不要懊恼,因为这实在太正常不过了,很多反模式的坑我也是亲身踩过的^-^   稍微修改几行代码就调试   对所有程序员来说,这个行为有一点心理上的原因:工程师都喜欢在做完一点修改之后,立即看到它的效果。
1070 0

相关实验场景

更多
AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等