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

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

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

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

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

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

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

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

可以用停机问题解释？

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

能测出来的那叫 BUG ？

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

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

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

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

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

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

来个宇宙直通图.jpg

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

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

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

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

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

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

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