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

[James369]

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


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

[James369]

我应该说出了很多程序员的心声，哈

[jasonyang9]

想到了这篇： https://web.archive.org/web/20051016203842/http://diveintomark.org/archives/2004/08/16/specs

[chendy]

但是市面上少说一半程序员做不到楼主说的这些。。。

[masterclock]

- 传入的参数控制好边界，非法值的判断:
第一个就无法认同：
一个测试工程师走进一家酒吧……

[sadfQED2]

我每次都写了各种 case 的单元测试，我代码提交后 qa 还会 review 代码，然后 qa 会写各种情况的功能测试用例。

然后，依旧经常出 bug，根本原因就是，屎山太大，总会出现各种根本意料不到的反人类情况

[jones2000]

上线以后 bug 多不多, 还是要看你的 test case 覆盖是否够, Code coverage 是否够了.

[IvanLi127]

@masterclock 测试工程师走进一家酒吧后点的东西不就是在测入参嘛？

[wsseo]

@chendy 一半太少了吧

[MiketsuSmasher]

@IvanLi127 酒吧开业了，顾客点了一份炒饭——测试工程师压根没往这方面想过——然后酒吧炸了

[sutra]

“我写的 bug 是过去的 /未来的 feature，但它却是现在的 bug 。”

[kkbblzq]

一颗钻石被丢上了屎山，很快它就被屎山淹没了。

[janxin]

为什么是“我”而不是我

[imbushuo]

实际上 Spec 写的不严谨，实现的人对 Spec 的理解有误差也会导致问题：Leslie Lamport 来我们这里做 tech talk 的时候提到过他发明 Paxos 的时候写了一份英文说明和一份数学证明，结果没人看后者，大家都看着前者实现；直到几年前 MSR 有个实习生提醒他原版英文说明里有一句话有歧义，理解错了那句话会导致实现有一个潜在的 bug，然后他们发现很多开源 Paxos 实现全部理解错了那句话，导致它们都有这个共有的 bug

他举这个例子说明 Spec 要用 formal 的东西写，比如说用 TLA+ 描述软件的行为

[Rocketer]

@MiketsuSmasher 酒吧点炒饭那个深有同感。

我曾经写过一段代码，需要根据数据库类型做不同处理。当时我们只有 MySQL 和 MongoDB，所以我写的 if…else...

结果一年以后有人在一个新模块中用了 Oracle，崩了……

[James369]

@janxin 因为有些夸大的成分，所以加了双引号

[jorneyr]

我们小公司，去年产生了 6000 多个 Bug，大多数都是开发人员写出的 Bug 。

[xuanbg]

我从来不会因为需求混乱造成 bug 。不吹牛地说，任何混乱的需求只要上我手，就不会混乱了。

然鹅，经常会有一些因为复制粘贴后忘记修改造成的小问题。这种 bug 一般自测一轮就都排除掉了。所以最终交付的产品基本没有 bug 。

[xuanbg]

@masterclock 是的，只靠严谨没用，只有抽象才能解决。管你几路来，我只一路去，就不会有一个测试工程师走进一家酒吧的各种问题发生了。

[Qseven]

当一个程序员有了足够的责任心和敬畏心，那么他写出的代码会少很多 BUG 。

[wipbssldo]

@Qseven 首先要有足够的时间