本文的一些观点可能会有少部分人不赞同，我也只是简单表达一下自己的想法。
1947 年 9 月 9 日，美国海军准将 Grace Hopper 在哈佛学院计算机实验室里使用 MarkII 和 MarkIII 计算机进行研究工作。她的团队跟踪到 MarkII 上的一个错误，操作人员发现是由于一只飞蛾钻到了 MarkII 的继电器里导致的。
团队清除了这只飞蛾，一切恢复正常。当时的工作人员记录了这样一句日志：“First actual case of bug being found.”这次著名的事件，犹如潘多拉打开了魔盒，从此，程序员的世界里，bug 满天飞。
1.趣谈：如何为 bug 找借口？
在我所担任过的角色中，有一个岗位叫做 Development Manager，通常简称 DM。记得在一次基于一款平台的二次开发项目中，因为 bug 实在太多，我们几乎拿出了一整个里程碑的周期来 debug，于是我这个 DM 有了新的解释：Debug Man。
没有人喜欢 bug，bug 意味着错误、不确定性、加班、交付风险……负面的词语怎么堆砌都不冗余。随便找个有过一、两个项目经验的开发者，问问他 debug 的回忆，那气氛就跟上坟一样。
对于 bug，开发者的神经往往也很敏感。有个段子很有趣——说的是“应该如何向程序员反馈一个 bug？”
你不能直接跟他说：“这里不对啊，是不是你程序有 bug 啊？”，要这么说的话，会直接被怼回来：“你丫的自己不会用吧！”。
你可以换个说法：“咦，这里好像不对，是我操作错了吗？”，这时程序员心里就一咯噔：“Shit...不会是我代码有 bug 吧？”
从业多年，发现有个现象还蛮有趣的：有时候，当某个 bug 被发现时，犯下这个错误的始作俑者会开玩笑地为自己解脱：“谁没写过 bug 啊，Windows 还有 bug 呢。”这句托词我也用过，感觉挺好用的，就好比：梅西都能罚丢点球，我空门没进，也是可以理解的嘛。
但其实吧……这逻辑经不起推敲的。
Windows 操作系统，一款长达 30 多年，装机量估计都超过了地球人口数量的巨型工程，复杂度基本只能靠猜。以微软公布的资料来看：
- Windows95 代码量约 1500 万行；
- WindowsXP 代码量约 4500 万行；
- WindowsVista 代码量约 5000 万行；
- Windows7 代码量 5000+万行。
以 Windows7 为例，超 5000 万的代码量，23 个小组，共 1000 多人的开发团队。如此规模下产生的 bug，和一个在办公室里上了 1 天班，写了 200 行代码，就闹出一堆 bug，搞得项目乱七八糟的，能同日而语吗？最后再轻描淡写地来句“微软也有 bug”，不害臊？
所以我后来不用这句了，如此开脱，水平太 low。其替代方案容我稍后再讲。
2.思考：我们能不能杜绝 bug？
为了对抗 bug，人们发明了各种各样的工具和手段，上至方法论，下至生产工具。越来越先进的 IDE，复杂的代码审查制度，从单元测试到集成联调，再配上 beta 版，试用，公测等等。凡此种种，其目标无一不是消灭 bug。可这些琳琅满目的解决方案的存在，反倒证明了一个悲剧：人类，实在是太容易犯错了。
如果说凡事都有正反两面的意义，那么 bug 的正能量就是硬生生造就了大量就业机会，进而维护了社会稳定。
那么，为什么我们总是无法避免 bug 的产生？我们能不能杜绝 bug？
答案当然是不可能了。因为那样一来，程序员的日子岂不是太舒服了？不符合苦蔽的定位。而且，我们所处的这个世界，但凡越是高呼要消灭的东西，越是会普遍地存在。就像苍蝇、蚊虫、污染、犯罪、战争，不一而足。
按照常识，经验越丰富的老手写出来的代码，一次通过的几率更高，比如他们思考得会更周全，对异常的判断和处理更老练，边界条件把握得更精确，等等。
所以我们可能会幻想：是不是只要我们足够仔细，并努力磨练技艺，通过让一部分码农先老练起来，然后实现共同老练，最终就可以达到全世界开发者联合起来消灭 bug 的大解放了？
很遗憾，这只是一个治标不治本的思路，因为 bug 是有阶级的。老手们的 bug 相对少，只是低级错误少，他们也会遇到 bug，而他们的 bug，往往都是一眼蒙逼的难度系数 N.x 的难题，不发生在代码层面，大多在业务层面，甚至需求设计层面，或者直接是一些不可抗拒因素（做过政府项目吗？）。
总之，不论是编程萌新还是编程老手都避免不了写出有 bug 的代码，况且谁还没有脑子短路的时候呢？
3.bug 还是 feature request？
bug 这个概念的起源，就预示着它的不可避免性。世界上第一个 bug 是一只飞蛾，这剧本，谁能料到？某种意义上说，bug 就是不可预见的错误，能被预估并且提前做好准备的，那叫 exception，try catch 是他们的朋友。
对于为什么会产生 bug 的原因，著名的荷兰计算机科学家 Edsger W.Dijkstra 有过一句经典名言：
“
If debugging is the process of removing software bugs，then programming must be the process of putting the min.
这就是上文提到的那句托词“Windows 也有 bug。”的替代方案。:)
设想一下，当你从无到有的写下一句句代码时，中间的任意一个时刻，你的程序都是运行不起来的，至少也是达不到目标效果的。从效用上完全等效于充满 bug 的一堆代码。你可能会辩解，程序还没写完呢，只是功能还没实现，并没有 bug。
事实上，换位思考一下，缺失某个功能和包含一个有故障的功能，对于用户而言，都是无用的。一个处于开发阶段尚没写完的代码和开发结束但写得有缺陷的代码，是一回事。
由此可以引申出一个著名的命题：That's not a bug，it's a feature request.
有时候，我们很难分清楚一个问题到底属于 bug 还是 feature request。文中作者抛出了一个案例：用 Visual Studio 构建一个 Windows GUI 程序时没有采用系统默认字体。这个算不算一个 bug 呢？
不好说。毕竟，随着软件应用越来越普及、越来越追求所谓人性化的趋势，传统意义上的只要程序能运行就不算 bug 的观点，也在慢慢发生改变。对于一个强迫症用户来说，UI 上有缺陷，那基本上整个软件就不能用了。
事实上，在当今各类 app 竞争白热化、同质化的时代，用户体验上的问题，往往是致命的。以前大家没得选，所以没那么挑剔，只要程序能干活就行了。如今的计算机用户已经被宠坏了，在这样的时代下，bug 早已悄悄地泛化了。
所以，到底如何才能写出没有 bug 的代码呢？
答案：不写代码。
一个悲观又绝望却正确的唯一解。
4.尽可能少写代码
试着在这绝望里挖掘一点希望吧。这个答案隐含了一个方法论：尽可能少写代码。因为 Dijkstra 大师已经说得很清楚了，编程就是制造 bug 的过程。
那么，代码写的越少，犯错的几率就越小，这个道理显而易见。维护一段 300 行的代码，我们很容易有信心；接手一段 3000 行的代码，什么反应就看个人素质了。
现代的开发方式也都包含有这个思路，从 IDE 的智能提示，代码补全功能，到每门语言都会有的各种“21 天从入门到精通”的开发框架，以及很多实战层面的约定俗成，都是在帮助开发者减少不必要的编码。框架化、规范化思维能降低出错的可能性。
事实上，就连编程语言本身的历史发展都是按照这个思路在进行。从底层的汇编语言，到 C/C++，再到 Java/C#/Python……等各种高级语言，语言演化的目的之一就是为了把程序员从脏活、累活的工作中解放出来。
“不要重复造轮子”的精神，一方面是在指导我们提高效率，不要重复劳动成本，另一方面也是减少重复犯错的几率。
当代 Web 开发中的各种包管理概念正深刻地践行着这条精神，以至于在 2016 年 3 月爆发了著名的 NPM&left-pad 事件：一段区区 11 行的字符串填充函数模块，被全世界依赖，结果作者 Azer 下架模块包的那一天，全球前端大崩溃。受波及的产品和团队中，甚至包含著名的 React！
这个事件让人们开始反思：我们是不是忘了该如何编程了？一个功能简单到人人都会写的函数，却都不约而同地选择引入，而不是自己实现。最终，过犹不及。
真所谓：NO BUG，NO CODE。
5.为什么要追求无 bug 呢？
可是，如果真的只能不写代码了，那么本身就已经没有女朋友的程序员们，现在连代码也没有了，这还让不让人活了？
不能这样把程序员们给逼死了，要讲人权。
有时候，当答案实在不可接受的时候，我们就该思考是不是问题问错了。
所以，换个角度，为什么要追求无 bug 呢？也许我们根本就没必要害怕 bug。
有 bug 的地方就有麻烦，有麻烦就有解决麻烦的需要，客户就是给那些能解决麻烦事的人支付报酬的。只处理简单的问题，是没有价值的，市场只认可那些面对困难能提供解决方案的人。简单来讲，想赚钱，就别怕麻烦。
对于客户来说，不管是 bug 或是 feature request，都是一个需要解决的问题。一个优秀的 PM（Project Manager），可以把客户反馈的 bug，包装成 feature request，返回一套解决方案。然后，优秀的商务代表出马，签订补充协议。恭喜，你们的项目经费增加了一点点。
英格兰有句谚语：Where there's muck，there's brass。
如此看来，“如何写出没有 BUG 的代码？”这问题，恐怕确实问错了。
转载：https://blog.csdn.net/weixin_45132238/article/details/106403779