为什么程序员老在改 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盘了。
壹言
复制链接去分享
1、快过年了，你的Bug改完了吗？
2、还有哪些原因导致了Bug的产生？
3、有没有什么简单的办法可以让Bug少一点？
求蓝牙音箱～～～～～～～
1099149711159403
复制链接去分享
他们有一句话是，生命不息，Bug不止。
离骚欧巴
复制链接去分享
刚解决一个bug，站点上传的图片清晰度降低了。
原以为是图片被压缩了，去检查代码，发现没问题，又检查nginx是否开了gzip压缩，也没有。
整了大半夜，又去检查reponse header，发现图片类型都被转成了webp。
😂
真是哔了狗了，再检查代码，还是没问题。
前前后后整了2个多小时，最后发现是接入的某cdn配置那里开启了 webp自适应
想减少bug，还是得增加经验与知识储备。
1661548926676456
复制链接去分享
程序是命令在运行的过程中，实际表现出来的效果和理论的效果有一定的出去，只有结合实际情况对编写的程序不断的优化，让程序达到一个最优的状态，优化bug是一个过程，目标效果才是我们的目的，bug是无穷无尽的………………
黄二刀
复制链接去分享
1、快过年了，你的Bug改完了吗？
改完是不可能改完的，今年是不可能改完的，如果年后辞职，只能留给下一任去找bug了。
2、还有哪些原因导致了Bug的产生？
程序逻辑不够严谨还有就是用户各种千奇百怪的操作习惯。
3、有没有什么简单的办法可以让Bug少一点？
有，不设断点，全靠猜。
1134250415047788
复制链接去分享
1、快过年了，你的Bug改完了吗？
没改完，但是bug要过年了
2、还有哪些原因导致了Bug的产生？
有新的需求就有bug
3、有没有什么简单的办法可以让Bug少一点？
换个工作
1341827085963991
复制链接去分享
bug产生于多种不确定性，如果都确定了呢，大部分场景都确定了呢，是不是就能减少bug，甚至消灭bug
无聊聊聊
复制链接去分享
1、快过年了，你的Bug改完了吗？
没有改完的时候！remain
2、还有哪些原因导致了Bug的产生？
bug产生的原因太多了，最近改的几个比较棘手的bug，都是不熟悉项目配置的人，改了某部分配置造成的，可以说是人为的bug。
3、有没有什么简单的办法可以让Bug少一点？
有，增加成本，代码提交要进行走查，经过评审再入库。
9亿少女梦
复制链接去分享
过完年，又回来写bug了，bug无休无止。人生处处是bug
陈_世_美
复制链接去分享
我认为没有哪个程序是没有Bug,因为每一次的测试完,需求不对或者是别的什么都会产生Bug,一个好的产品就是不断的修改Bug,从而呈现好的产品给客户.
large_rour
复制链接去分享
3.熟悉使用的技术，语言与载体平台的兼容性吧，这样可以提前改掉很多bug。
1724419996519005
复制链接去分享
Bug无处不在。
祭酒。
复制链接去分享
🙄🙄后天就要上班了，而我，放假期间除了睡觉啥也没干，坐等回公司加班修改bug。
小白在哪里
复制链接去分享
此时此刻的我，只想早点回去写代码
非洲考拉
复制链接去分享
没有，，，只能留着跨年了。。
