软件系统一旦出现 bug，绝大多数情况下是 需求混乱导致的。

[James369]

写了这么多年的软件，已经练就了一身铜墙铁壁，不吹牛的说，“我”写出来的代码基本没有什么 bug 。
更确切的说是在软件层面很少出现什么 bug，为什么，主要还是得益于严密的思维，丰富的经验积累，比如：
～ 传入的参数控制好边界，非法值的判断。
～ 所有的异常情况考虑周全，捕获到位。
～ 严格按照接口规范处理。
～ 返回码 /错误码处理到位。
～ 不写花里胡哨 /晦涩难懂的代码。
～ 谨慎处理并发 /异步 /回调。
～ 注意对象的生命周期，引用释放。
～ 写完一个功能，立马自测一遍。
...
这种防御式的编程模式，基本做到了滴水不漏。所以给出去的软件模块 99%都不会有问题。


然而 bug 终究会产生，这个时候“我”发现，大部分的 bug 都源自需求的混乱不勘，功能的杂乱堆叠，业务的纠缠不清。
所以，再强大的软件设计师，都会被不好的需求搞死。（比如考虑各种兼容性，比如强行让一只鱼飞上天）
这也是为什么再牛逼的操作系统也是 bug 连绵，补丁不断，因为需求太复杂了。

[jslang]

测试的时候不是很到位

[jslang]

或者没有经过测试

[JaguarJack]

没时间！！！

[raaaaaar]

首先要有意识，再有能力，最后还要有足够的时间。太过于理想化，很多时候只能说有这个意识就够了，慢慢迭代就好，不可能一劳永逸的。

[imnpc]

很多时间是没有足够的时间测试 忙的时候 只能先开发完功能 让客户配合测试

[kop1989]

与其说是需求太复杂，不如说是覆盖不住处理需求的成本。
而且成本不能 100%覆盖需求，是软件工程的常态。

所以我们能做的，就是尽量的高效利用成本。（这里的成本包括但不限于时间、人力、项目风险等等）
所以必然程序中充满着面向效率的妥协。

bug 也就因此产生。

[kop1989]

这就像是，造一个一千年不倒塌的房子不难，难在你要在有限的成本以内造。

[wolfie]

项目管理问题 高于 需求变更

[liuidetmks]

@Rocketer 哈哈,这个锅是不是甩到你头上了。老代码为新需求造成的 bug 负责

[chanchan]

需求混乱?经常整个工作过程都很混乱其实

[liuidetmks]

@kop1989 有些需求甚至在部分情况下是矛盾的。有时候为了节约时间 /偷懒，
目前业务不会覆盖到的逻辑就忽略了，或者 加一个永远不会再看一眼的 TODO

后期需求又有变动. gg

[User9901]

甩锅 101
好好看好好学，圈起来要考的

[wat4me]

需求太多，时间太少。

[wat4me]

@wat4me 你和代码必须有一个能准时跑。

[duhb]

时间够怎样都行，最主要的是时间不够问题。

[jack778]

技术层面避免 bug 相对简单，但是业务逻辑很多是有坑的，稍微理解不透彻就出 bug 了。你永远不知道你的用户会怎么使用你的系统。

[jack778]

@masterclock 只要让我看到你的源码，我就有办法让你的边界防御失效

[desdouble]

talk is cheap, show me the code.

[clf]

还有就是对业务理解的偏差导致的。后端接口按业务逻辑实现了，前端以为按 UI 写好就行了，结果调接口的时候能给你整出一堆花活。

[sexyback]

刚参加工作没多久，因为公司的项目经常做实验，效果好了就规模化，有时候需求不能很明确，经常改动，现在真心理解楼主的话