1947年9月9日，美国海军准将Grace Hopper在哈佛学院计算机实验室里使用MarkII和MarkIII计算机进行研究工作。她的团队跟踪到MarkII上的一个错误，操作人员发现是由于一只飞蛾钻到了MarkII的继电器里导致的。
团队清除了这只飞蛾，一切恢复正常。当时的工作人员记录了这样一句日志：“First actual case of bug being found.”这次著名的事件，犹如潘多拉打开了魔盒，从此，程序员的世界里，bug满天飞。
▲世界上第一个bug
趣谈：如何为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。其替代方案容我稍后再讲。
思考：我们能不能杜绝bug？
为了对抗bug，人们发明了各种各样的工具和手段，上至方法论，下至生产工具。越来越先进的IDE，复杂的代码审查制度，从单元测试到集成联调，再配上beta版，试用，公测等等。凡此种种，其目标无一不是消灭bug。可这些琳琅满目的解决方案的存在，反倒证明了一个悲剧：人类，实在是太容易犯错了。
如果说凡事都有正反两面的意义，那么bug的正能量就是硬生生造就了大量就业机会，进而维护了社会稳定。
那么，为什么我们总是无法避免bug的产生？我们能不能杜绝bug？
答案当然是不可能了。因为那样一来，程序员的日子岂不是太舒服了？不符合苦逼的定位。而且，我们所处的这个世界，但凡越是高呼要消灭的东西，越是会普遍地存在。就像苍蝇、蚊虫、污染、犯罪、战争，不一而足。
按照常识，经验越丰富的老手写出来的代码，一次通过的几率更高，比如他们思考得会更周全，对异常的判断和处理更老练，边界条件把握得更精确，等等。
所以我们可能会幻想：是不是只要我们足够仔细，并努力磨练技艺，通过让一部分码农先老练起来，然后实现共同老练，最终就可以达到全世界开发者联合起来消灭bug的大解放了？
很遗憾，这只是一个治标不治本的思路，因为bug是有阶级的。老手们的bug相对少，只是低级错误少，他们也会遇到bug，而他们的bug，往往都是一眼蒙逼的难度系数N.x的难题，不发生在代码层面，大多在业务层面，甚至需求设计层面，或者直接是一些不可抗拒因素（做过政府项目吗？）。
总之，萌新有萌新们的秀逗，大叔有大叔们的短路，老杆也会有自己的滑铁卢。
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的代码呢？
答案：不写代码。
一个悲观又绝望却正确的唯一解。
尽可能少写代码
试着在这绝望里挖掘一点希望吧。这个答案隐含了一个方法论：尽可能少写代码。因为Dijkstra大师已经说得很清楚了，编程就是制造bug的过程。
那么，代码写的越少，犯错的几率就越小，这个道理显而易见。维护一段300行的代码，我们很容易有信心；接手一段3000行的代码，什么反应就看各人素质了。
现代的开发方式也都包含有这个思路，从IDE的智能提示，代码补全功能，到每门语言都会有的各种“21天从入门到精通”的开发框架，以及很多实战层面的约定俗成，都是在帮助开发者减少不必要的编码。框架化、规范化思维能降低出错的可能性。
事实上，就连编程语言本身的历史发展都是按照这个思路在进行。从底层的汇编语言，到C/C++，再到Java/C#/Python……等各种高级语言，语言演化的目的之一就是为了把程序员从脏活、累活的工作中解放出来。
“不要重复造轮子”的精神，一方面是在指导我们提高效率，不要重复劳动成本，另一方面也是减少重复犯错的几率。
当代Web开发中的各种包管理概念正深刻地践行着这条精神，以至于在2016年3月爆发了著名的NPM&left-pad事件：一段区区11行的字符串填充函数模块，被全世界依赖，结果作者Azer下架模块包的那一天，全球前端大崩溃。受波及的产品和团队中，甚至包含著名的React！
这个事件让人们开始反思：我们是不是忘了该如何编程了？一个功能简单到人人都会写的函数，却都不约而同地选择引入，而不是自己实现。最终，过犹不及。
写代码，真的很难。NO BUG，NO CODE。
为什么要追求无bug呢？
可是，如果真的只能不写代码了，那么本身就已经没有女朋友的程序员们，现在连代码也没有了，这还让不让人活了？
不能这样把程序员们给逼死了，要讲人权。
有时候，当答案实在不可接受的时候，我们就该思考是不是问题问错了。
所以，换个角度，为什么要追求无bug呢？也许我们根本就没必要害怕bug。
有bug的地方就有麻烦，有麻烦就有解决麻烦的需要，客户就是给那些能解决麻烦事的人支付报酬的。只处理简单的问题，是没有价值的，市场只认可那些面对困难能提供解决方案的人。简单来讲，想赚钱，就别怕麻烦。
对于客户来说，不管是bug或是feature request，都是一个需要解决的问题。一个优秀的PM，可以把客户反馈的bug，包装成feature request，返回一套解决方案。然后，优秀的商务代表出马，签订补充协议。恭喜，你们的项目经费增加了一点点。
英格兰有句谚语：Where there's muck，there's brass。
如此看来，“如何写出没有BUG的代码？”这问题，恐怕确实问错了。
