搜公众号
推荐 原创 视频 Java开发 开发工具 Python开发 Kotlin开发 Ruby开发 .NET开发 服务器运维 开放平台 架构师 大数据 云计算 人工智能 开发语言 其它开发 iOS开发 前端开发 JavaScript开发 Android开发 PHP开发 数据库
Lambda在线 > 程序人生 > 为什么程序员老在改 Bug,就不能一次改好吗?

为什么程序员老在改 Bug,就不能一次改好吗?

程序人生 2019-04-23
举报

为什么程序员老在改 Bug,就不能一次改好吗?

程序员的日常三件事:写Bug、改Bug、背锅。连程序员都自我调侃道,为什么每天都在加班?因为我的眼里常含Bug。

但是真的有这么多Bug要改吗?就不能一次改完吗?

程序员听这问题后要拍键盘了,还!真!不!能!


为什么程序员老在改 Bug,就不能一次改好吗?

用户使用场景的不确定性


在日常生活中,即便每个物品都有使用说明书,可一千个用户就有一千种使用方式。例如用诺基亚手机砸核桃,用iPad当切菜板,所以说程序是确定的,但用户的使用场景是不确定性的。

各种不按套路出牌的操作会给系统带来挑战,例如网上有个段子说:

一个人走进一家酒吧,要了一杯啤酒

一个人走进一家酒吧,要了一杯咖啡

一个人走进一家酒吧,要了0.7杯啤酒

一个人走进一家酒吧,要了-1杯啤酒

一个人走进一家酒吧,要了2^32杯啤酒 

一个人走进一家酒吧,要了一杯洗脚水

一个人走进一家酒吧,要了一杯蜥蜴

一个人走进一家酒吧,要了一份asdfQwer@24dg!&*(@ 

一个人走进一家酒吧,什么也没要 

一个人走进一家酒吧,又走出去又从窗户进来又从后门出去从下水道钻进来 

一个人走进一家酒吧,又走出去又进来又出去又进来又出去,最后在外面把老板打了一顿 

一个人走进一家酒吧,要了一杯烫烫烫的锟斤拷 

一个人走进一家酒吧,要了NaN杯Null

一个人冲进一家酒吧,要了500杯啤酒咖啡洗脚水野猫狼牙棒奶茶 

一个人化装成老板走进一家酒吧,要了500杯啤酒并且不付钱 

一万个人在酒吧门外呼啸而过 

一个人走进一家酒吧,要了一杯啤酒 ';DROP TABLE 酒吧 

一个人跳进一家酒吧。 

一个人蒙着眼睛,倒退着走进一家酒吧。 

一个人走进一家酒吧,要了一杯美国啤酒,一杯德国啤酒,一杯比利时啤酒,一杯青岛啤酒。

一个体重五百吨的人走进一家酒吧。

一个酒量五百吨的人走进一家酒吧。

一个酒量为零的人走进一家酒吧。 

一个人走进一家酒吧,点了一杯啤酒,一边喝一边用指尖把啤酒逼出体内。 

一个人来到一家酒吧门口,拿出电脑,敲了几个命令,2^32 - 1 个测试工程师走进一家酒吧。 

一个人戴着墨镜,手持两把 Uzi 冲进一家酒吧,对着室内一顿扫射,然后要了一杯啤酒。 

一个人走进一家酒吧,要了一杯Nil,一杯Null和一杯None 

一个名叫exception的人走进一家酒吧,被丢了出来 。

我走进酒吧要了一杯">_ <”

我盗用老板身份走进了酒吧进了后台放了一瓶我自己的酒。

我走进酒吧在吧台放了一杯' or 1=1。

最后酒吧炸了。

软件设计中最大的现实是:设计难以完全覆盖现实。

一个简单的搜索框,测试用例高达几十个。可以说只要用户在使用系统,系统就存在Bug。

而程序员在编程时只能按照需求与经验覆盖大部分用户的使用场景,剩下的只能是见一个Bug灭一个。


为什么程序员老在改 Bug,就不能一次改好吗?

需求的不确定性


之前有“AI都会编程了,要程序员干嘛”的言论,造成很多程序员产生焦虑纷纷要转行。

等等,说这话的人肯定没问过产品经理。

互联网公司的两大谎言一是程序员说的“没问题,上线吧”,二是产品经理说的“就按这个做”,现实是“我还要改几十版哦”。

产品经理自己没想明白需求要做成什么样子呢,在AI做出一个百分百正确无Bug的软件前,它学会给产品拍砖的可能性会更大。

随着产品不断迭代,不断增加的代码自带Bug时,还可能会给原有程序引入Bug。有时候涉及底层代码的修改,一旦出问题,有可能会带来多米诺骨牌效应。

还有时候是程序好好跑着,Bug从天上来。例如圣诞节阿里的Antd彩蛋Bug,又如在2005 年日本瑞穗证券的交易员输入错的股价,想撤销可被系统拒绝,导致造成400亿日元的损失。后来证实系统出Bug了,这个Bug是在2000年埋的。

所以很多公司会严格要求在程序修改后必须经过严格的回归测试,来验证对其他业务流程有没有影响。


为什么程序员老在改 Bug,就不能一次改好吗?

程序员不是机器


程序员是人,不是机器,人做事是主观判断性去做的,再加上“禀赋效应”:心里头自动地给自己写的代码添一层滤镜,觉得自己写的代码没有问题,所以程序员总找不出自己的Bug。

这导致程序员日常的第四件事是:挖坑填坑。有人大手一挥,一大段代码不写注释,或业务方法不用公共定义,不拆分类,一个方法写了一千行,从此没人敢动这些烂代码。也有人默默地“感谢”前任给他有活干,一点点地将坑填上。

还有对开发流程的漠视也是导致系统Bug多的原因。有开发心想“我只是改了两行代码,不影响业务流程”,心想提给测试太麻烦了,便自顾上线了。

结果线上就出Bug了。

所以公司才设定各种软件开发规范来减少Bug的产生,例如提测前开发之间的Code Review和需经过测试人员的测试才能上线。

程序不是一蹴而就地做出来的,Bug也不是一时半会能改完的。毕竟“写程序不像是造一座桥,而是造一座城。”

为什么程序员老在改 Bug,就不能一次改好吗?

# 欢迎来评论区留言 #

快过年了,你的Bug改完了吗?

为什么程序员老在改 Bug,就不能一次改好吗?

为什么程序员老在改 Bug,就不能一次改好吗?

为什么程序员老在改 Bug,就不能一次改好吗?

 热 文 推 荐 

print_r('点个好看吧!');
var_dump('点个好看吧!');
NSLog(@"点个好看吧!");
System.out.println("点个好看吧!");
console.log("点个好看吧!");
print("点个好看吧!");
printf("点个好看吧!");
cout << "点个好看吧!" << endl;
Console.WriteLine("点个好看吧!");
fmt.Println("点个好看吧!");
Response.Write("点个好看吧!");
alert("点个好看吧!")
echo "点个好看吧!"


点击“阅读原文”,打开 CSDN App 阅读更贴心!


喜欢就点击“好看”吧

版权声明:本站内容全部来自于腾讯微信公众号,属第三方自助推荐收录。《为什么程序员老在改 Bug,就不能一次改好吗?》的版权归原作者「程序人生」所有,文章言论观点不代表Lambda在线的观点, Lambda在线不承担任何法律责任。如需删除可联系QQ:516101458

文章来源: 阅读原文

相关阅读

举报