查看原文
其他

程序员与 Bug

小象君 计算机与网络安全 2022-06-01

信息安全公益宣传,信息安全知识启蒙。

加微信群回复公众号:微信群;QQ群:16004488

加微信群或QQ群可免费索取:学习教程

教程列表见微信公众号底部菜单


“哥们,又在写 Bug 呢?”据说这是对程序员杀伤力最大的一句话,没有之一!之所以如此,那是因为这是句大实话啊!


程序员的人生

就是 Bug 和 Debug 交织在一起的悲歌

尽管每天都要和 Bug 打交道

可你是否知道

Bug 这个叫法是怎么来的吗?

上图中那个黑乎乎的东西

就是史上第一个程序 Bug——

一只烧糊的蛾子

1947 年

哈佛大学的计算机 Harvard Mark II

突然停止了工作

程序员们费尽周折

终于找到了问题的关键

就是这只死掉的蛾子

这就是 Bug 这种叫法的来由

那时

哈佛二代没有二极管和晶体管

是继电器计算机

靠无数个噼啪作响的电子元件运作

时常有电弧闪光出现

这只蛾子被闪光所吸引

毅然决然地扑了上去……

从此

从此永垂不朽

其实

Bug 虽然人人能写

但也有高低之分

总体来说

水平越高的程序员

Bug 写得越是牛逼…

不信?

我们来看看这些大神级的 Bug


吊炸天的 Google APP


前阵子

谷歌推出了一个好玩的 APP

Google Arts & Culture

用户可以上传自己的自拍照

系统会将照片与艺术画作进行对比

匹配出一张

和用户长得很像的

画作中的人物肖像

社交网络顿时沸腾了!

人们纷纷晒出自己的自拍匹配成果

有些效果确实不错

有些就比较尴尬了

画面太美不敢直视

不得不说

这哥们确实长得很屌…

出现这样的 Bug

只能归咎于脸部识别技术尚不完全成熟了

希望 Google 能早点改掉这些 Bug

让他们重新做人…


Bumblebee 惊天 Bug


如果不是 Bumblebee 开源项目

你会相信

一个空格也能导致系统瘫痪吗?

安装后,

usr/会被删掉

至于后果有多严重?

看下图…

怎么样?怕了吧?


500 英里的 Bug


来源:知乎用户郭智明


信用卡关联 Bug


对这位仁兄的遭遇

小象君深表同情…


见怪不怪的微软 Bug


敢问 Outlook

你究竟干了什么伤天害理的事?

连亲妈都不认你了!

……


那些匪夷所思的 Bug


有些 Bug 的出现让人百思不得其解

fix 后除了无奈

更让人哭笑不得


1.我叫刘伟楠,凭啥屏蔽我?


这位刘伟楠童鞋

想以实名注册新浪微博

但他发现只要涉及“刘伟楠”三个字

甭管加怎样的前缀后缀

都会注册失败

即便以其他名称注册成功后

更改昵称为“刘伟楠”也同样无法实现

该童鞋万般无奈之下发了帖子

一时间响应者无数

最终在网友齐齐声讨下

新浪微博取消了该项屏蔽

不过至于为什么会出现这样的 Bug

新浪微博并没有给出解释……


2.飙高音造成笔记本死机


最终解决方案:

把固定硬盘的螺丝紧了紧

固有频率改变

硬盘就不共振了

3.X 射线带来的 Bug


Quora 上有位程序员

讲述了这样一个经历

他为医院急救设计了一个相关程序

在实验室运行良好

但是每次在医院调试都出 Bug

作者只好到医院去现场调试

经过漫长的测试终于发现

是由于医院使用的 X 射线

导致电脑内存总是丢失几个 bit 的信息

致使程序出问题!

最终的解决方案是

把电脑的内存用铅板隔起来!

4.硬盘分区搞死人


故事发生在工厂

工厂里有 14 条线

其中一条线的 zebra 打印机

在打印标签时

比其他线要多耗时 3 秒左右

即便打印的东西完全一样

因为产线一直在生产

所以没法在线 Debug

只能在线外模拟

但模拟结果一直都显示正常

问题始终无法解决

后来干脆换了电脑,fix了!

最后看了下硬盘的分区格式

服务器是 NTFS

这台电脑的 D 盘是 NTFS

而E盘居然是 FAT32!!!

谁特么这么干的!

粗来!保证不打死你!

5.中文和英文符号的差异


请童鞋们看看

如上两段代码有什么不同?

一模一样是吧?

但实际上第二行可以运行

第一行却无法运行

至于原因

分享的童鞋最后说了

中文的-和英文的-外表没有不同

但编码就是不一样……


6.微信大小写坑爹


一位程序员自述

3 月份负责公司微信公众号开发

当时的后台是技术领导写的,C#

公众号支付的预定单和加密全在后台

后来后台改版本

由 C# 改为 Java

结果调了一晚上

显示签名错误

技术领导看了好久也不知道怎么回事

C# 的代码和 Java 的代码对了一遍

发现没问题

又把微信公众号配置也看了一遍

也没问题

各种百度、各种猜想

各种验证,都不对……

几乎把网上的说的问题都查了一遍

还是不对……

最后去微信官网看了开发者文档

发现上面预定单的 APP ID 的 i 是大写

但支付的时候是小写!

于是,fix 了……


不是 Bug 的 Bug


有些程序员习惯了 Bug 与 Debug 的节奏

遇到问题

往往第一时间进行 Debug 处理

结果好不欢乐

下面我们来听听

他们和 Bug 的那些事


1.Bug 是 WiFi


刚进公司做 iPad 应用

公司给了两台测试机:

一台 iPad4

一台 iPad Air

应用里面有个资源下载功能

同一个资源用同一段代码

不过在 iPad Air 上下得飞快

在 iPad4 上面就慢如龟爬

一直搞不懂是什么问题

两边程序都是一模一样

但到底为什么会有这么大的差别呢?

曾天真的设想

是不是两台不同型号的设备内部

某个网络相关的硬件不一样

导致下载速度不一样呢?

然后不断 Google、百度查资料

看帖看论坛看博客

希望找找看有没有前辈遇到这种怪问题

然而找了 3 天还是找不到……

到了最后……

特么发现

那台 iPad4 连的

是楼下咖啡店的 WiFi……

2.图像为啥黑屏


直播伴侣

是给主播用的视频美颜的工具

眼下各大直播平台都普遍采用

有一次程序作了大的架构调整

结果发现图像黑屏了

就下断点一步一步查

先检查采集 SDK 给我的数据是否有问题

再看看 GPU 图像数据缓冲区

最后终于找到了问题

fix 了

但第二天这个问题又出现了

摄像头又一次黑屏了

于是又开始设断点

检查采集的图像数据

检查 GPU 里的缓存数据

检查经过美颜

经过图像识别处理后的数据

但是反复检查

就是没有发现任何问题!

心急如焚之际

突然发现

摄像头的正面扣在地上

直挺挺的竖在那儿

于是把摄像头拿起

问题解决……


游戏 Bug


作为程序员

每次玩游戏遇到 Bug

总会设身处地地想

这哥们到底怎么搞的?

猎魔人

魔兽世界

质量效应

人物和画面出现问题

是游戏 Bug 基本的表现形式

不过这还算好的

起码情节没耽误

下面这种情况就让人无奈了:

我是团里里最厉害的大神

今天要打团战

突然我连人带马嵌到了鼓里

怎样也甩不掉 

想通过栅栏与鼓分离

结果栅栏也甩不掉了

没时间了,出城吧!

栅栏比城门宽,出不去

无法从城门走

那用轻功吧!

结果……

连人带马嵌入了城墙里

无奈只得联系客服

说人能下来,但——

打团战怎能没坐骑?

然后客服给了我——

生活中遇到的 Bug


浸淫行业数年

练就了一双火眼金睛

对于各类 Bug 最是敏感

比如:

弱弱地问下

这趟是星际高铁吗…

受宠若惊!

您这是跨省来接我的吗……

……

每次遇到这种情况

小编总会幻想

如果我中意的妹子遇到 Bug

憋慌!

除了写 Bug

我们更擅长 Debug!


程序员这样跟外行解释编程


下面以买苹果为例说明程序员如何解决问题。


程序员需要对问题进行透彻的分析,理清其涉及的所有细节,预测可能发生的所有意外与非意外的情况,列出解决方案的所有步骤,以及对解决方案进行尽量全面的测试。


而这些正是我认为编程难的地方,任何一点遗漏都会成为 Bug,轻则导致挨骂,重则导致经济损失甚至危害安全。


普通人:我今天要买一斤苹果。


程序员:我今天要买一斤苹果。

  • 因为我只喜欢红富士苹果,所以我只买红富士苹果。

  • 我能接受的最高价格是 10 元/斤。

  • 正常情况下一斤苹果用一个袋子能装下,但是为防万一,我会带两个袋子。

  • 我知道附近的3家水果店,所以我会依次访问这 3 家水果店。


根据上述条件,我设计出以下的买苹果的流程:


(以下区域,可以左右拖动查看完整内容)

买苹果流程开始
   对水果店0、水果店1、水果店2依次执行:
   拜访一家水果店流程开始
       走到此水果店
       如果此水果店没有开门,则结束当前的“拜访一家水果店流程”
       如果此水果店没有苹果,则结束当前的“拜访一家水果店流程”
       如果此水果店的苹果当中没有红富士苹果,则结束当前的“拜访一家水果店流程”
       如果此水果店的红富士苹果剩余不到一斤,则结束当前的“拜访一家水果店流程”
       如果此水果店的红富士苹果的价格高于10元/斤,则执行3次:
       讲价流程开始
           询问店主是否愿意将价格降到10元/斤或更低
           如果店主愿意,则跳过剩余的“讲价流程”
       讲价流程结束
       如果此水果店的红富士苹果的价格仍然高于10元/斤,则结束当前的“拜访一家水果店流程”
       打开一个袋子,将其作为当前的袋子
       重复执行以下流程,直到总重量大于一斤:
       装袋一个苹果流程开始
           从所有的不在袋子中的红富士苹果中选出最好的一个
           如果此苹果能装入当前的袋子,则将此苹果装入当前的袋子,否则执行:
           换袋子流程开始
               如果我有剩余的袋子,则从中任意选出一个并作为当前的袋子,否则执行:
               向店主要袋子流程开始
                   向店主索要一个袋子
                   如果店主拒绝给我袋子,则将我的所有袋子里的所有苹果取出,然后结束当前的“拜访一家水果店流程”
                   将店主给我的袋子作为当前的袋子
               向店主要袋子流程结束
           换袋子流程结束
           测量我的所有袋子里的所有苹果的总重量
       装袋一个苹果流程结束
       根据我的所有袋子里的所有苹果的总重量和店主给出的价格,计算我应付的价格
       向店主询问我应付的价格
       如果我不接受店主索要的价格,则执行3次:
       校对流程开始
           向店主解释我计算出的价格,并询问其是否同意
           如果店主同意,则跳过剩余的“校对流程”
       校对流程结束
       如果我仍然不接受店主索要的价格,则将我的所有袋子里的所有苹果取出,然后结束当前的“拜访一家水果店流程”
       如果我没带钱,则将我的所有袋子里的所有苹果取出,然后结束当前的“拜访一家水果店流程”
       付钱拿走苹果
       跳过剩余的“拜访一家水果店流程”
   拜访一家水果店流程结束
买苹果流程结束


这个流程怎么样?我来设计一些测试样例,测试一下这个流程。


测试发现一个问题:如果水果店 0 和水果店 1 都有红富士苹果并且价格都低于 10 元/斤,而且水果店 1 的价格比水果店 0 更低,那么我希望买水果店 1 的苹果,但我设计的流程会让我买水果店 0 的苹果。


为了解决这个问题,我应该先询问所有水果店的价格,然后去价格最低的那一家买苹果。


经过修改,我重新设计出以下的买苹果的流程:


(以下区域,可以左右拖动)

买苹果流程开始
   对水果店0、水果店1、水果店2依次执行:
   询问一家水果店的红富士价格流程开始
       走到此水果店
       如果此水果店没有开门,则视此水果店的红富士价格为无穷大元/斤,并结束当前的“询问一家水果店的红富士价格流程”
       如果此水果店没有苹果,则视此水果店的红富士价格为无穷大元/斤,并结束当前的“询问一家水果店的红富士价格流程”
       如果此水果店的苹果当中没有红富士苹果,则视此水果店的红富士价格为无穷大元/斤,并结束当前的“询问一家水果店的红富士价格流程”
       如果此水果店的红富士苹果剩余不到一斤,则视此水果店的红富士价格为无穷大元/斤,并结束当前的“询问一家水果店的红富士价格流程”
       向店主询问此水果店的红富士苹果价格并记录
   询问一家水果店的红富士价格流程结束
   从3家水果店中选出红富士价格最低的一家(如果有并列则随机选择),将其作为目标水果店
   如果目标水果店的红富士苹果价格为无穷大元/斤,则结束当前的“买苹果流程”
   走到目标水果店
   如果此水果店的红富士苹果的价格高于10元/斤,则执行3次:
   讲价流程开始
       询问店主是否愿意将价格降到10元/斤或更低
       如果店主愿意,则跳过剩余的“讲价流程”
   讲价流程结束
   如果此水果店的红富士苹果的价格仍然高于10元/斤,则结束当前的“买苹果流程”
   打开一个袋子,将其作为当前的袋子
   重复执行以下流程,直到总重量大于一斤:
   装袋一个苹果流程开始
       从所有的不在袋子中的红富士苹果中选出最好的一个
       如果此苹果能装入当前的袋子,则将此苹果装入当前的袋子,否则执行:
       换袋子流程开始
           如果我有剩余的袋子,则从中任意选出一个并作为当前的袋子,否则执行:
           向店主要袋子流程开始
               向店主索要一个袋子
               如果店主拒绝给我袋子,则将我的所有袋子里的所有苹果取出,然后结束当前的“买苹果流程”
               将店主给我的袋子作为当前的袋子
           向店主要袋子流程结束
       换袋子流程结束
       测量我的所有袋子里的所有苹果的总重量
   装袋一个苹果流程结束
   根据我的所有袋子里的所有苹果的总重量和店主给出的价格,计算我应付的价格
   向店主询问我应付的价格
   如果我不接受店主索要的价格,则执行3次:
   校对流程开始
       向店主解释我计算出的价格,并询问其是否同意
       如果店主同意,则跳过剩余的“校对流程”
   校对流程结束
   如果我仍然不接受店主索要的价格,则将我的所有袋子里的所有苹果取出,然后结束当前的“买苹果流程”
   如果我没带钱,则将我的所有袋子里的所有苹果取出,然后结束当前的“买苹果流程”
   付钱拿走苹果
买苹果流程结束


现在这个流程是不是完美了呢?不是,我还能发现很多问题。


如果 3 家水果店都有红富士苹果但都不到一斤,但是三家店加起来能达到一斤,那么我不应该结束流程回家,而是应该把三家店的红富士苹果都买下来。


如果我向水果店询问价格的时候这家店还有红富士苹果,但我询问完所有水果店的价格后这家店的红富士苹果卖完了,那么我的流程会让我试图处理不存在的红富士苹果。


我走路的过程中可能会遇到突发事件,比如发现了新的水果店,比如袋子破掉了苹果掉一地,对于这些情况我的流程都无法进行处理。


啊......问题太多了我懒得再改流程了,我还是去 X 宝买吧。那么接下来我要设计一个在 X 宝买红富士苹果的流程……

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存