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

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

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

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

酒吧 炒饭

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

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

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

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

还是兼容

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

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

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

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

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

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

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


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

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

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

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

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

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

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

这要从软件工程复杂性从何而来说起
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 脚本语言的创建者，并且以在分布式操作系统和存储系统中的工作而闻名