程序员修改那些丧心病狂的BUG,得知真香后瞬间崩溃!

我们经历的大部分bug有的被其他人修复了并且在互联网分享出来了,这时候我们通过Stackoverflow、Baidu、Google等搜索引擎找到答案了。但是我们在工作中也可能会遇到一些疑难的bug,这里bug我们在搜素引擎上找不到解决方案,可能好几天都不得其解,这些迟迟没有解决的bug往往搞得人焦头烂额。

《程序员修改那些丧心病狂的BUG,得知真香后瞬间崩溃!》

那作为一个苦逼的程序员,究竟碰见过哪些丧心病狂的bug呢?下面,我们来看看他们与bug的故事。

小A:

写JS,自己手机没电了,拿同事老张的安卓机调试,很简单的获取用户微信昵称,结果死活获取不到,一直显示为null。应该是跨平台问题,因为之前在自己iPhone上是没有bug的,拼命看api文档,但是都没提到这方面。急死我了。……刚刚老张告诉我他的昵称就是null。……老张已被打死……前面夸张修辞,老张最后当然没死,腿打断了而已。

《程序员修改那些丧心病狂的BUG,得知真香后瞬间崩溃!》

电商行业程序员老K:

也谈谈自己遇到的一个bug吧,我之前是做电商的,某较大的电商平台,突然有一天,C2C的店主反馈,看到的订单不是自己的,看到后台的商品列表也不是自己的。当时在睡午觉,看到这个问题,立马吓醒了,平时5个投诉就是一个故障单,那还都是一点体验上的小问题,这种订单混乱,商品混乱的错误,真是要紧急死了于是,主管,总监都来看这个问题,一群大佬在后面看着,赶紧找最近几天的发布,测试情况,一个个回退,一个个检查,最后都无法解决问题,要知道时间一分一秒过去,半个小时还解决不了就要出大事了后续又有用户来投诉,直接电话联系,远程控制电脑,发现操作起来巨慢,于是顺口问了一下用户的网络是什么网络。结果他说是:“某城宽带”,一瞬间,有点感觉了,继续问其他几个投诉的客户都是“某城宽带”,然后我们打电话到那个宽带的运营商,得到的回复是“年底了,为了省流量,他们做了一部分缓存”他们做了缓存做了缓存……缓存……存……可是为毛TM的动态请求还做缓存啊,修改商品和订单的时候,随机返回成功或者失败 ……1.这个和时间戳也没关,我们都加了token的,他们也忽略了

2.你没猜错,他们把POST和GET动态请求也缓存了,就是说你提交了一个POST修改商品的请求,他从环缓存里面随便丢个回复给用户,用户感觉修改成功了,其实请求根本没到我们这边,是的,就是这么丧心病狂。

《程序员修改那些丧心病狂的BUG,得知真香后瞬间崩溃!》

系统管理员老王:

从前我是个系统管理员,平时去机房登录服务器时都是站着操作。有一次腰疼,搬了个凳子坐在了机器前面,完蛋,死活登录不进去,提示密码错误。于是我站了起来,重新输入了一次密码,进去了。后来我觉得奇怪,于是抽时间做了测试,发现:只要一坐下,就密码错误,站起来就好了。这个 Bug 在我的职业生涯中持续了好几年,一直以为是什么灵异事件。直到有一天公司升级设备给我换了个键盘。原来是老键盘上有两个键装反了,站着打字是看着键盘,坐着盲打就错了,真的是很无语啊……

为了修改BUG,程序员们也是煞费苦心啦!

至于如何能高效地修改BUG呢?给大家提一些建议

先根据情况试一下下面的步骤:

  1. 换个环境试试
  2. 换个用户试试
  3. 换个操作方式试试
  4. 换一下数据试试
  5. 换个浏览器试试
  6. 换个版本试试

根据上的情况搞清楚下面这几个问题:

  1. 这个BUG什么情况下出现?什么情况下不出现?两种情况的区别在哪里?
  2. 这个BUG之前没有,现在出现了,中间都动了什么?
  3. 这个BUG生产环境出现测试环境不出现,两个环境区别是什么?
  4. 同样的功能,这样操作没有BUG,那样有BUG,两个操作的区别是什么?

《程序员修改那些丧心病狂的BUG,得知真香后瞬间崩溃!》

  1. 输出结果与预期不符,这种BUG一般都是由于代码逻辑错误造成的,如果能在开发环境重现,最好解决方法就是单步调试,设定每一步代码的预期结果,然后跟踪判断实际结果是否与预期结果一致,不一致的分析原因,如果在开发环境无法重现,无法单步调试的,可以采用添加输出日志的方式判断哪一步的问题。

  2. 系统异常报错,这种情况下需要提取日志,找出错误堆栈信息,这时候最重要的事情是要把堆栈信息看懂、看完整。这是很多经验不足的程序员常见的问题,就知道报错了,报的什么错,这个错代表什么一概不知。而且往往堆栈信息是一个套一个输出。

  3. 系统Crash,这个问题常见的原因是负载过高、并发过高、或者配置错误。最常见的就是内存溢出。这时候要首先排除配置错误的原因,主要靠查看Crash Log来分析原因,如果Crash Log没有有用的信息,就得排查硬件、内存、网络等方面的设置,看是否有配置错误的地方。再找不到就在测试环境用开发模式进行压测和调试。

  4. 系统响应缓慢,这种问题一般是存在资源竞争或者系统资源不足的情况,先检查服务器内容、CPU、网络情况,如果服务器压力过大,排查应用系统负载情况是否异常,如果这些数据都正常,就需要排查代码中的性能瓶颈,可以采用profile工具或者直接输出时间戳的方式查看哪个操作占用时间最长。特别需要留意依赖第三方接口的情况,比如同步的方式发送邮件、发送短信、写文件等。

这里推荐一下我的前端技术分享群:731771211,里面都是学习前端的,如果你想制作酷炫的网页,想学习编程。自己整理了一份2018最全面前端学习资料,从最基础的HTML+CSS+JS【炫酷特效,游戏,插件封装,设计模式】到移动端HTML5的项目实战的学习资料都有整理,送给每一位前端小伙伴,有想学习web前端的,或是转行,或是大学生,还有工作中想提升自己能力的,正在学习的小伙伴欢迎加入学习。

点击:加入

    原文作者:IT智云编程
    原文地址: https://www.jianshu.com/p/5d27ef9b6a96
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞