做程序员好多年了，一直有个疑问，几乎没有一个程序或者功能是完全一次性写完不修 bug 的

[xiaotuzi]

由于最近写小工具，自认为很简单，而且写的时候还是比较认真，但还是写了些 bug ，回想起自己这么些年，每次做功能都要重新去 check 代码，debug 代码，真的感觉经验并不能完全取代 bug 的产生，写代码至少要多重复一遍，大家有没有这种感觉？还是只有我自己才这样？

感谢大家的回复，看到大家对 bug 的理解，我突然就有些懂了。。。
写代码和解决 bug 实际上是一套的流程，并非一次写完就结束了，这个结束可能并不是完整的流程，而 bug 的出现，让整个写代码的流程得到了完善，让代码更准确。（星星眼）

[hamsterbase]

先写好单测，然后再写逻辑.

逻辑写完 测试通过，就可以发布了。

[xuanbg]

你我皆凡人，思虑不周，有 bug 很正常的好不好。重点不在于有没有 bug ，在于 bug 能不能在上线前被发现并修复。

譬如我，只有 2 种 bug 。一种是莫名其妙不讲理的，基本上是第三方的锅。当然这种非常少。
另一种是非常低级的，只要测试就必定发现的。大多数是手写 sql 的语法错误，或者加了个什么字段结果实体类上没加这些。。。所以，我只要做一次接口测试，通过后就极少有 bug 了。

[zhuwd]

出生就毕业，不用改 bug 的项目不都早凉透了吗

[hyperbin]

依据哥德尔定理连数学本身都是不完备的，更别提不靠谱图的人脑编写出的逻辑电路（任何软件都能用等价的数字电路来实现）

[zhumengyang]

最好的程序就是没有程序

[lsk569937453]

单元测试没有吗？

[yyysuo]

你为什么会有这种不切实际的想法？

[xiaotuzi]

@hamsterbase 我是说不单元测试之前的情况下，一次性写完一个完整功能，不出现 bug 。

[cassyfar]

程序没 bug 只有一种可能，没人用

[xiaotuzi]

@xuanbg 确实，做一次测试之后，很少有 bug ，可能是我追求过高了。。。

[xiaotuzi]

@yyysuo 可以追求一下，突破自己的极限。

[aqtata]

https://github.com/kelseyhightower/nocode

这个项目就没有 BUG

[ChrisYoung]

我认为和经验，业务熟悉度，业务复杂度都有关系，我最大的改变是之前报的是修为低的 bug 比如空指针等，现在稍微修为低些的 bug ，通过检查代码，代码 review ，完善的自测基本都避免了。另外一点就是没有完美的程序，能满足当前业务场景的程序那就够了。

[SomeBodsy]

理论上来说，不存在没有 bug 的程序。不然从程序员早就失业了

[xiaotuzi]

@ChrisYoung 说得对，好了，我要开始堆屎山了

[gpt5]

我也时常困惑，但凡是代码总有 bug ，这个是不是受某个基本定律支配的。

[wjx0912]

如果道是完美的，那么操作系统就是完美的，如果操作系统是完美的，那么编译器就是完美的，如果编译器是完美的，那么应用程序就是完美的，所以用户心满意足，整个世界因此和谐。

[xtreme1]

@gpt5
System F 和它的所有超集的类型推断是不可判定的.

[shuxhan]

恭喜你发现人类社会的规则，不断完善和发展进步。
如果你想一次性写好一个程序不存在 Bug ，难度不亚于原始社会直接过度成星际社会

[FLADIMIR]

因为程序是对现实的抽象，在这个过程中人怎么可能面面俱到呢？

[8355]

越简单的代码和设计越不容易有 bug ，需求和现有系统足够复杂 bug 是必然存在的，即使代码本身没有 bug 也可能因为一些外界因素导致异常产生。

[wuqi5920]

代码没有 bug ，你还能继续干下去？

[NoKey]

修修补补，改一下，加一下需求，才有可持续性。。。

[wuqi5920]

@zhuwd 没有 bug 是测试被开还是开发被开对吧

[yafoo]

一直感觉自己大脑逻辑有点问题，在上高中时，经常考试，有次考试突破了记录，一张卷子最后的 10 几道大题，全是在最后的几步加减乘除出错了...

现在写程序也一样，再简单的程序，总是会出 bug ，然后再反复修 bug

[zfy941]

有些 bug 根本不是 bug
需求和用户规模都是会变的
同一个程序 就算自身不出问题 也不会一直满足要求

[sunnicholas]

几乎没有就还是有，找原因总结，出 bug 只能说出了概率就是逻辑不严谨

[Sfilata]

越简单的程序就越不会有 Bug ，例如让你写一个 Hello World 。大多数人会一次性写出来而且没有 Bug 吧。

[liuxingdeyu]

没有银弹，从软件工程上看，bug 量只是一个指标，还有周期、人力成本之类的一堆指标，当一个方程出现的时候，更多的是求个相对情况下的最优解

[wenzhuo]

@aqtata 你小子就先杀生是把·

[JinTianYi456]

有人的地方就有江湖 :D

[scegg]

成本。

如果给你无限多的时间，你大可以一次写出无 bug 的程序。然而并没有任何意义。

[ZhuWenJian]

去医院看病好多次了，几乎没有那次是医生开一副药就能治好的。都是去好几次，开好几次药才好的。

[woodfizky]

1 、预测到使用场景的所有可能性，每种可能性都有对应的处理；
2 、编码水平足够且不粗心；
3 、使用的轮子/依赖的第三方代码/接口/编程语言甚至操作系统层面没有 bug ；

这样可以在编码阶段就减少 bug

[reallynyn]

因为这世界上没有完美的东西，越是复杂的事物越是如此。
你见到的所有东西都是可以用但不完美的，包括你开的车也存在设计问题，你住的房也存在施工问题，只不过通过大量的冗余抵消了不良后果。

[ZhuWenJian]

所以吧，人无完人，除非你做的事情比较简单。
不然在没有大量的时间去研究调查的情况下，快速上手开发，出 bug 是必然的。

[hetingting]

没有 bug 的程序，是不完美的

[standchan]

有啊，你就打印一个 hello world ，大概率就永远可以正常打印了

[q8164305]

因为理论上的逻辑分支是指数增长的，而不是线性增长的，所以人脑考虑所有的逻辑分支几乎是不可能的事

[carytseng]

我很少写单元测试，一般用 postman 工具点一下就可以了

[luomao]

我现在写代码，如果出 bug 我觉得在我预期之类，反倒是完全测不出 bug 会让我有种有隐藏 bug 没有复现的感觉。人无完人，写 bug 难免的，但别总是出低级 bug 。

[cmdOptionKana]

为什么人类发现万有引力那么难，明明每个人看各种东西掉在地上看过无数遍了，就是想不到万有引力。

为什么人类发现相对论那么难，需要顶级的天才。

量子力学就更难了，为什么那么难？因为本来就是那么难，本来就该那么难。

零 bug 也一样，复杂度摆在那里呢，本来就是很复杂的逻辑交织在一起。

[victorc]

是你的问题

写代码一遍过是完全做得到的，多练习，提高专注力

[qping]

越庞大的系统，越多人参加，bug 就会越多

增加各种测试可能是唯一的办法：单元测试，集成测试，系统测试

[oneisall8955]

有时候会把判断条件写反了，自测才发现😂

[la2la]

我只有在进入那种全神贯注感觉周围什么都听不见那种状态写的代码错误率极低，不过很少很少有这个状态

[luobingit]

测试先行

[iblessyou]

不用纠结，我现在打字写东西，明明感觉写的时候都好着，但写完难免发现很多错别字。
看小说你会发现网文作者自己也会每章写完对一下错字。
所以出 bug 很正常，这个情况只要在你自己写完后的测试时发现解决了就可以。

[HyperionX]

刷题少了

[realpg]

我自己写的有很多，因为自己的代码标准，注释标准，加上人工测试覆盖较好。

协作的很难

[eycode]

那个不是 bug ，是程序运行另一种展示，只是我们接受不了这种展示而已。手动狗头.jpg

[cwcc]

人不能保证建造的房子一块砖瓦都不掉，一块油漆都不刮花，也不能保证自己房子绝对不会倒，这个逻辑应用到代码上同样适用。

[iOCZ]

万物皆 bug

[tkHello]

要环保 采用一次性程序员

[Mutoo]

是的，就连大名鼎鼎的 knuth 也没办法做到 0 bug
https://en.wikipedia.org/wiki/Knuth_reward_check

[duanxianze]

现代人类相比几万年前的人类几乎没有进化，步入工业时代更是只有短短几百年，知足吧，兴许再过几十万年人类就能进化到脑内编译代码了

[darksword21]

我就问你时间能不能倒流 🐶

[xz410236056]

@hamsterbase #1 不是学计算机的吧，你这种叫 TDD 。早八百年前就有了，没 BUG 了吗

[crazyzzm]

think more, code less.
敲代码前思考越全面，敲代码时思路能更清晰，bug 也就能更少了

[RageBubble]

你在追求一件虽然有可能做到但毫无意义的目标。有这功夫不如多测试几下，让自己的程序更 robust

[kemistep]

CRTL+ C + CRTL +V ，Bug 比较少

[samin]

@hamsterbase
只能尽可能降低问题出现，并且大概率是防止功能性问题，Bug 还分为业务性、用户性，单元测试一般无法穷举

[Zy143L]

得看是啥类型的 bug
很多时候都是非预期输入

[pkoukk]

做设计规划可能不会有 BUG ，但是你打字肯定会偶尔打错两个字的
专业作家写小说都要一审二审三审，人名写串那也是常事
写代码的时候偶尔脑子抽了，变量用错了，赋值位置错了，那不是很正常？

[Knights]

计算机为了解决现实中的问题，需要抽象、模拟现实的环境，然而现实世界是随机的、混沌的；
程序发布后，如果没人维护，逻辑就固定了，然而使用它的人、使用它的目的、运行它的硬件都可能发生变化，现在的计算机是无法自行面对这混沌的现实的。

[encro]

我可以不改或者少改，
就是我自己先做原型，
然后写伪代码，
最后将写代码变为填空，
这样就不会错了，
如果你学会我的方法，
可以开发一套写伪代码生成代码的系统，
就是一套 AI 了，
我就被替代了。。。

[encro]

另外一个程度来说：
没有人用的代码就不会出错，反过来有人用一定有 BUG 。。。菜刀杀人是刀的 bug 吗？

[qqlax]

可以用停机问题解释？

[catch]

没有严重 bug ，小问题慢慢修复

[alphat]

能测出来的那叫 BUG ？

[atwoodSoInterest]

这个问题几乎等同于人会不会老，理想情况下最棒的代码就是的程序和代码就是对客观事物的完美转述，然而事务本身就在变化，代码怎么可能不变化呢？
当然了，如果只是讨论静止于某一个时刻的某一个特定需求的话，那是有可能办到的，不过难度很大而已。只要这个需求本身够小，场景够清晰，每个人就都能写出来，比如写一个函数输出 1+1 的结果，这个我相信每个人都能写出来 bug free 的代码。

[libook]

现在写代码本质上就是开发速度和质量方面的平衡，对一方面有要求就得另一方面有所妥协。

所以才会有软件测试工程学的存在，可以使用各种方法论来保障一定程度的质量的基础上尽可能提升速度。

[xd666888]

@xuanbg 你没写过逻辑 bug 吗？ 🤣

[junas7]

@aqtata 我宁愿什么都不做，也不愿犯错

[GeorgeWai]

程序是给人用的，人的需求有时候连自己都说不清，需求一旦变化了，bug 就出来了。当然一半 bug 是程序员不严谨导致的。

[LXGMAX]

来个宇宙直通图.jpg

[xloger]

算有的吧，我之前写了个摸鱼的小程序给群里朋友们内部玩，功能就是我写好了一个鱼池里面有很多鱼，稀有度不一样，分数文案不一样。每个用户可以每天摸一次。
基本上是一次写好也没 Bug 。因为需求清晰实现也简单，经验丰富一点的程序员问题都不大。

然后后来加了加成功能，可以特定时机触发特殊的效果，又加了限定活动等等，Bug 就多了起来。

程序的实现简单来说分为：需求到程序员的映射，程序员把这个需求到代码的映射，程序员本身对编程的掌控力度。
第一个映射出问题就是需求理解不一致；第二个映射出问题就是我们开发时自己考虑不周全，很常见；第三个就是我们的编程水平体现，但是需求足够简单的话问题其实不多。

所以要是这三方面问题都不大那自然没啥 Bug 。但是一旦迭代起来了，一二三部分都很容易出现问题。

[maxxfire]

这是由于程序的抽象性导致的，程序不直观，无法一眼看出问题

[Bongzyu]

因为人没办法做到全知全能。

[loryyang]

这本来就很难做到的，但是是可以有办法提升的，比如长期的编码锻炼，当然还有许多规范、最佳实践，可以提升代码的质量

[lzgshsj]

宇宙是混沌，程序员没法观测到所有的运行分支

[FeatureProbe]

没有，就像没有一个人可以从婴儿到成年没有生过病（无论大小病）的人。

[fyibmsd]

bug 不是程序的对立面 而作为程序的一部分与之永存

[wdssmq]

酒吧 炒饭

[huyi23]

来泼一盆冷水，出 bug 是正常的，但是几乎没有一个程序或者功能是完全一次性写完不修 bug 的，真的是能力问题，bug 能接受，但是一堆 bug 确实无法接受，影响整组开发。

[dif]

很难做到无 bug 吧。
第一，对需求的理解，如果不到位那么写出来的东西肯定有 bug 。
第二，测试很刁钻，在咖啡馆点了个炸弹（点白酒已经被瑞幸实现了）。乍一看不合理，但真有这样做的用户（也有可能是别有用心的人）。
第三，目前我接触到的工作环境，很难给你多少时间去思考怎么能够完善，或者完美的写出一套逻辑。（恶心的日报机制）。所以大家都是需求来了大概理解一下就开始上手干了，不然日报没法交代。

[Daniel17]

首先这种情况就不可能存在

[xiaotuzi]

@dif 我说的是自认为写的没有 bug 了，结果一测试就有 bug ，没有说需求和业务逻辑的关系。单纯就是自我感觉。

[43n5Z6GyW39943pj]

还是兼容

[dayeye2006199]

TDD 可解。
最近还是体会到这个东西的好处。

其实非常符合人脑思考问题的流程

[AmosLi]

chatGPT 第一次给你的代码也跑不起来

[nutting]

linux 很多内置的东西，比如 awk ，sed ，还有 shell 本身，有的应该是 20 年没更新了吧，不知道是不是有 bug

[hazardous]

有啊，上次写了个验证，一二十行代码，竟然一次就跑通了，那成就感简直爆棚了！

[zpf124]

有啊，写一些简单的 CRUD 功能基本上很快就写完了，算上关联查询、树形结构数据，文件上传都几乎没 bug 。

偶尔发现的 bug 主要以输入的值入参校验没很细导致的直接保存失败之类的，比如字段超长，输入文本正则校验遗漏了某一类格式。


然而，没有人能一次性想好所有的功能细节，那么初版完成之后随着业务思路的梳理总会有一些小改动，这些改动反倒很容易引起之前没有的漏洞。

因为写初版功能的时候，我脑子里的思路是完整的包含从头捋到尾的完整思路， 而后续对于某些细节改动时，就像打补丁，很容易只梳理了改动的点，而忽略这个改动对实现原有初版流程的影响，这时候我脑子里只有这一小段片段，没有完整的流程，几乎代码的 80%功能性 bug 都是这里产生的。

[54xavier]

代码写完有 bug 其实没什么，没 bug 才恐怖，有时候明明觉得这里没有判断好，那里可能有潜在的问题，急急忙忙上线，发现用户用的好好地，什么问题都没有，那才是叫人感到恐怖！

[nuk]

得看谁用吧，主体功能达到了，其他小 bug ，我可以当作它们不存在，顾客在酒吧点锟斤拷炸了酒吧关我包工头啥事情。。

[rpish]

有个指标叫做千行代码缺陷率。
我觉得这个指标的存在侧面说明了 bug 产生不可避免。

[GuardX]

#inlcude<stdio,h>
int mian()
{
printf("hello world")
}
好吧，确实做不到

[BUHeF254Lpd1MH06]

额都做了这么久程序员了，还能问出这个问题吗

[charlie21]

这要从软件工程复杂性从何而来说起
https://www.sohu.com/a/524801828_612370
https://github.com/Cactus-proj/A-Philosophy-of-Software-Design-zh
https://zhuanlan.zhihu.com/p/590534099?utm_id=0 浅谈 A Philosophy of Software Design 软件设计哲学 作者：John Ousterhout Tcl 脚本语言的创建者，并且以在分布式操作系统和存储系统中的工作而闻名