怎样写出没有bug的代码？
1947年9月9日，美国海军准将Grace Hopper在哈佛学院计算机实验室里使用 Mark II 和 Mark III 计算机进行研究工作。她的团队跟踪到 Mark II 上的一个错误，操作人员发现是由于一只飞蛾钻到了 Mark II 的继电器里导致的。团队清除了这只飞蛾，一切恢复正常。当时的工作人员记录了这样一句日志：“First actual case of bug being found.” 这次著名的事件，犹如潘多拉打开了魔盒，从此，程序员的世界里，bug 满天飞。
世界上第一个 bug
在我所担任过的角色中，有一个岗位叫做 Development Manager，通常简称 DM. 记得在一次基于一款平台的二次开发项目中，因为 bug 实在太多，我们几乎拿出了一整个里程碑的周期来 debug，于是我这个DM有了新的解释：Debug Man.
没有人喜欢 bug，bug 意味着错误、不确定性、加班、交付风险，等等…… 负面的词语怎么堆砌都不冗余。随便找个有过一、两个项目经验的开发者，问问他 debug 的回忆，那气氛就跟上坟一样。
对于 bug，开发者的神经往往也很敏感。有个段子很有趣 —— 说的是“应该如何向程序员反馈一个 bug ” ——
你不能直接跟他说：“这里不对啊，是不是你程序有 bug 啊？”，要这么说的话，会直接被怼回来：“你丫的自己不会用吧！”。
你可以换个说法：“咦，这里好像不对，是我操作错了吗？”，这时程序员心里就一咯噔：“Shit… 不会是我代码有 bug 吧？”
从业多年，发现有个现象还蛮有趣的：有时候，当某个 bug 被发现时，犯下这个错误的始作俑者会开玩笑地为自己解脱：“谁没写过 bug 啊，Windows 还有 bug 呢。” 这句托词我也用过，感觉挺好用的，就好比：梅西都能罚丢点球，我空门没进，也是可以理解的嘛。
但其实吧…… 这逻辑经不起推敲的。
Windows 操作系统，一款长达30多年，装机量估计都超过了地球人口数量的巨型工程，复杂度基本只能靠猜。以微软公布的资料来看：
Windows 95 代码量约 1500 万行
Windows XP 代码量约 4500 万行
Windows Vista 代码量约 5000 万行
Windows 7 代码量 5000+ 万行
以 Windows 7 为例，超5000万的代码量，23个小组，共1000多人的开发团队。如此规模下产生的bug，和一个在办公室里上了1天班，写了200行代码，就闹出一堆bug，搞得项目乱七八糟的，能同日而语吗？最后再轻描淡写地来句 “微软也有 bug ”，不害臊？
所以我后来不用这句了，如此开脱，水平太low。其替代方案容我稍后再讲。
为了对抗 bug，人们发明了各种各样的工具和手段，上至方法论，下至生产工具。越来越先进的 IDE, 复杂的代码审查制度，从单元测试到集成联调，再配上 beta 版，试用，公测，等等。凡此种种，其目标无一不是消灭 bug 。可这些琳琅满目的解决方案的存在，反倒证明了一个悲剧：人类，实在是太容易犯错了。
如果说凡事都有正反两面的意义，那么 bug 的正能量就是硬生生造就了大量就业机会，进而维护了社会稳定。
那么，为什么我们总是无法避免 bug 的产生？我们能不能杜绝 bug ？
答案当然是不可能了。因为那样一来，程序员的日子岂不是太舒服了？不符合苦逼的定位。而且，我们所处的这个世界，但凡越是高呼要消灭的东西，越是会普遍地存在。就像苍蝇、蚊虫、污染、犯罪、战争，不一而足。
按照常识，经验越丰富的老手写出来的代码，一次通过的几率更高，比如他们思考得会更周全，对异常的判断和处理更老练，边界条件把握得更精确，等等。所以我们可能会幻想：是不是只要我们足够仔细，并努力磨练技艺，通过让一部分码农先老练起来，然后实现共同老练，最终就可以达到全世界开发者联合起来消灭bug的大解放了？
很遗憾，这只是一个治标不治本的思路，因为bug是有阶级的。老手们的bug相对少，只是低级错误少，他们也会遇到bug，而他们的bug，往往都是一眼蒙逼的难度系数N.x的难题，不发生在代码层面，大多在业务层面，甚至需求设计层面，或者直接是一些不可抗拒因素（做过政府项目吗？）。总之，萌新有萌新们的秀逗，大叔有大叔们的短路，老杆也会有自己的滑铁卢。
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 them in.
这就是上文提到的那句托词 “ 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 或是 feature request，都是一个需要解决的问题。一个优秀的PM，可以把客户反馈的 bug，包装成 feature request，返回一套解决方案。然后，优秀的商务代表出马，签订补充协议。恭喜，你们的项目经费增加了一点点。
英格兰有句谚语：
Where there’s muck, there’s brass.
如此看来，“ 如何写出没有BUG的代码？” 这问题，恐怕确实问错了。
怎样写出没有bug的代码？相关推荐
- 请问：如何写出没有BUG的代码？
全世界只有3.14 % 的人关注了 数据与算法之美 1947年9月9日,美国海军准将 Grace Hopper 在哈佛学院计算机实验室里使用 Mark II 和 Mark III 计算机进行研究工作. ...
- 如何写出更好的代码（文末有福利）
女主宣言 我们在过去的几期推送里已经给大家介绍了笔者根据多年研发经验总结出来的编码规范和 git 等实用工具的运用场景,今天咱们就来继续聊聊项目开发过程的诸多方法论.本文最先发布于 7rule,转载已 ...
- 两大方案，只为写出更安全的代码！
[CSDN 编者按]安全漏洞的源头是开发,只有当开发人员写出了包含安全漏洞的代码,黑客才有机可乘.因此,如何保障开发写出更"安全"的代码,是安全防护工作中最重要的一环. 作者 | ...
- 如何一本正经地写出别人无法维护的代码？
作者 | 阿木 责编 | 伍杏玲 出品 | 程序人生(ID:coder_life) 编写除了自己没人能看懂的代码,是一种怎样的体验? 下面由作为资深挖坑程序员的我,手把手教大家这是怎么做到的?如果各位 ...
- [翻译Joel On Software]Joel测试：12步写出更高质量代码/The Joel Test: 12 Steps to Better Code
Joel on Software The Joel Test: 12 Steps to Better Code Joel测试:12步写出更高质量代码 byJoel Spolsky Wednesday, ...
- 如何写出更优雅的代码——编程范式简述
<如何写出更优雅的代码--编程范式简述>源站链接,阅读体检更佳! 什么是程序? 1976年,瑞士计算机科学家,Algol W,Modula,Oberon 和 Pascal 语言的设计师 N ...
- jvm大局观之内存管理篇: 理解jvm安全点,写出更高效的代码
jvm大局观之内存管理篇: 理解jvm安全点,写出更高效的代码 - 知乎 前言 本篇是java内存区域管理系列教程之一 - 在得知GC Root的组成之后,如何在垃圾回收发生的时刻,找到GC Root ...
- php代码如何写得好看,如何写出优雅的PHP代码
如何写出优雅的PHP代码 导语:PHP是一种通用开源脚本语言.语法吸收了C语言.Java和Perl的特点,利于学习,使用广泛,主要适用于Web开发领域.下面我们来看看如何写出优雅的PHP代码,希望对大 ...
- 作为一名程序员，怎样写出高效简洁的代码？
前言: Hello大家好,我是Dream .经常有朋友问我,自己写的代码太乱,虽然功能都能实现但是写的并不简洁,让人一眼看上去就会很难受,那如何去写出简洁优雅的代码呢?那今天我就来和大家分享一下一些写 ...
最新文章
- Rancher部署Traefik实现微服务的快速发现
- 数据结构——排序：插入排序、选择排序、交换排序、归并排序、基数排序
- java利用求余水仙花数_java求水仙花数
- 时间序列 预处理 python_【Python算法】时间序列预处理
- linux下添加，删除，修改，查看用户和用户组
- HTML文本下划线效果,聊聊CSS中文本下划线_CSS, SVG, masking, clip-path, 会员专栏, text-decoration 教程_W3cplus...
- java 图文生成图片_java生成图片
- linux常用命令笔记大全
- COLING 2020 | 字符感知预训练模型CharBERT
- 可以做技术，切不可沉湎于技术，大家怎么看？
- Visual C++ 2005 系列课程学习笔记-6
- sql常用语句之DDL
- Android微信授权登录闪退,如何解决微信闪退问题 四种解决微信闪退无法登录的原因及方...
- 英文歌曲：cross every river( 穿过每一条河 )
- 怎么查看网站的域名 如何查询网站的IP地址
- pytorch系列教程(四)-自定义损失函数
- Vector 自定义Sort
- Python3-笔记-B-002-数据结构-字典dict{ }
- ARVE: Augmented Reality Applications in Vehicle to Edge Networks
- 单体架构、SOA和微服务