为什么程序员老在改 Bug,就不能一次改好吗?
程序员的日常三件事:写Bug、改Bug、背锅。连程序员都自我调侃道,为什么每天都在加班?因为我的眼里常含Bug。
但是真的有这么多Bug要改吗?就不能一次改完吗?
程序员听这问题后要拍键盘了,还!真!不!能!
有文章总结了这么几条,我摘了一部分:
1、用户使用场景的不确定性
在日常生活中,即便每个物品都有使用说明书,可一千个用户就有一千种使用方式。例如用诺基亚手机砸核桃,用iPad当切菜板,所以说程序是确定的,但用户的使用场景是不确定性的。
软件设计中最大的现实是:设计难以完全覆盖现实。
一个简单的搜索框,测试用例高达几十个。可以说只要用户在使用系统,系统就存在Bug。
而程序员在编程时只能按照需求与经验覆盖大部分用户的使用场景,剩下的只能是见一个Bug灭一个。
2、需求的不确定性
之前有“AI都会编程了,要程序员干嘛”的言论,造成很多程序员产生焦虑纷纷要转行。
等等,说这话的人肯定没问过产品经理。
互联网公司的两大谎言一是程序员说的“没问题,上线吧”,二是产品经理说的“就按这个做”,现实是“我还要改几十版哦”。
产品经理自己没想明白需求要做成什么样子呢,在AI做出一个百分百正确无Bug的软件前,它学会给产品拍砖的可能性会更大。
3、程序员不是机器
程序员是人,不是机器,人做事是主观判断性去做的,再加上“禀赋效应”:心里头自动地给自己写的代码添一层滤镜,觉得自己写的代码没有问题,所以程序员总找不出自己的Bug。
这导致程序员日常的第四件事是:挖坑填坑。有人大手一挥,一大段代码不写注释,或业务方法不用公共定义,不拆分类,一个方法写了一千行,从此没人敢动这些烂代码。也有人默默地“感谢”前任给他有活干,一点点地将坑填上。
那么,我想问:
1、快过年了,你的Bug改完了吗?
2、还有哪些原因导致了Bug的产生?
3、有没有什么简单的办法可以让Bug少一点?
阿里云代金券 x 3
品牌U盘 x 1
小米随身蓝牙音箱 x 1
cjsoldier
已获得小米随身蓝牙音箱
复制链接去分享
1、快过年了,你的Bug改完了吗?
刚换了家公司,我也不想频繁跳槽,奈何被裁员了。新公司正在做一个类似于阿里中台的东西,现在刚开始做,没有bug要改。
2、还有哪些原因导致了Bug的产生?
举个例子,开发环境有100个jar包,生产环境有300个jar包。 结果发布到生产环境,跑起来之后才发现有jar包冲突了。
为什么生产环境会有这么多Jar包?因为还有其他小组的人在发布应用。 比如发布spark应用。
如果走正规流程的话,需要到pre环境跑一下,需要提前提交上线的资料,比如一些配置文件,sql文件之类的。而且流程走完了,是不允许临时改东西的。
如果流程不正规的话就会导致混乱,上线的时候丢三落四的。可怕的是刚上线没问题,过了一段时间才发现有东西忘加了。我不知道大家怎么定义bug的,我觉得上线的时候有问题,这就算是bug了。
3、有没有什么简单的办法可以让Bug少一点?
我觉得测试驱动设计(TDD)是一个非常好的办法。
上次给一个开源项目提交了一个PR,自己没测试充分就提交上去了,人家那边测试case就没跑过。果然,有一个地方没考虑到,新的bug产生了。同时我也明白了,人家当初那样写是有原因的。
TDD能减少bug还有一个重要原因: 当我们写测试代码觉得有困难的时候,说明我们的代码设计是有问题的。一段好的代码,一定是非常容易测试的,是不需要powermock这样的东西的。 反过来说,因为用了TDD,我们自测的时候变得容易了,所以我们更愿意复测自己的代码了。 为什么我们的代码测试不充分?我想很大的原因是我们嫌麻烦,所以干脆就不测了吧。当然有强烈责任心的除外。
从开发人员的角度来说,我感觉TDD是比较简单的办法了,毕竟我们的工作就是撸代码的。
钟元大老爷
已获得品牌U盘
复制链接去分享
1、快过年了,你的Bug改完了吗?
没有, 90多个bug和缺陷,改剩下30多个。
2、还有哪些原因导致了Bug的产生?
3、有没有什么简单的办法可以让Bug少一点?
浮生递归
已获得阿里云代金券
复制链接去分享
1、快过年了,你的Bug改完了吗?
用户有点少,所以bug发现的也少,该改的都改完了。
2、还有哪些原因导致了Bug的产生?
用户数量多导致bug(发现)多,也是各重要原因。这就是为什么windows的bug远远多余unix。用户基数完全不一样,导致发现的数量也完全不一样。结果就是微软天天在发布补丁来修bug。
3、有没有什么简单的办法可以让Bug少一点?
有的,让用户少用你的产品就行了。或者自己选择那些用户数量少的产品来开发。我做的软件,基本都没多少用户使用,所以也基本没发现过多少bug。就算发现了,也不用担心造成多大影响,毕竟没几个人在用。
我现在正在用打车软件去单位上班的路上,这打车软件导航也出bug了。导航路线居然不是导航到终点的,而是另外不知道什么鬼的目的地,还好司机熟路。看来这软件的开发小哥春节不好过了。
海阔天空yy
已获得阿里云代金券
复制链接去分享
1、快过年了,你的Bug改完了吗?
我的Bug一般只要有时间就会立即改的,到目前为止发现的bug都解决了。
2、还有哪些原因导致了Bug的产生?
没有命名规范和代码规范。
对输入输出的数据不做验证
崩溃问题
技术难点问题
由于技术人员的粗心,所导致的问题。
UI问题
临时的需求变更问题。
需求写的有
外部原因
3、有没有什么简单的办法可以让Bug少一点?
从以上几点出发,控制好原因,应该就能减少bug
wangccsy
已获得阿里云代金券
复制链接去分享
1、快过年了,你的Bug改完了吗?
没有改完。BUG是不可能改完的,只是改到系统可以接受为止。
2、还有哪些原因导致了Bug的产生?
主要原因:需求不明确,改来改去。
其它原因:技术实现制限,自己对使用技术不够了解。开发过程中不仔细,单元测试不足,沟通不到位等。
3、有没有什么简单的办法可以让Bug少一点?
基本上不太可能吧。不过还是有一些办法的,一是对需求的控制,二是加强单元测试(单元测试是程序员对自己代码最好的测试),三是良好的沟通,特别涉及到接口,模块间的通信时。
我要U盘,就差U盘了。