不是在写Bug，就是在DeBug

一、Bug的渊源

软件Bug的故事，早在二战时期就已经开始了，而且还是指针和虫子之间的事儿。程序员与Bug，从霍波女士开始，就是一对冤家，这便是Bug与DeBug。自此，Bug和DeBug也就成了程序员的日常。它不仅昭示着人类认知的局限性，也印证着人类对认知的努力。

随着程序员职业的繁荣，在这一职业内部分化出更多的细分工种。前端与后台，开发工程师和测试工程师等，在外行看来他们都是IT工程师。就像财经行业里的会计、出纳和总账之间一样，外行都叫会计，以为会计都是算账管钱的。

实际上他们各司其职，在各自的专长上达到效率最大化，才有了行业里，一部分人写Bug，一部分人DeBug。才有人打趣地说：不是在写Bug，就是在写Bug的路上。不是在DeBug，就是在DeBug的路上。

二、Bug的危害

当Bug还是一只真虫子的时候，它引发了指针电路的短路，损毁了机器。Bug从一开始就是期望的破坏者。尽管现代软件中的Bug极少能导致硬件损毁的，但是它所造成的后果仍然让人难以承受。

一方面，正如John Kemeny（曼哈顿计划的参与者和BASIC的缔造者）就电子计算机对人类影响的评估那样，人类越来越高度依赖电子计算机。程序中的Bug，如果导致了错误的结果，人类又相信了这些错误的结果，后果将是灾难性的。诸多航天航空事故、航海事故就是例证，更别提现在的AI应用了。

Bug成为软件业的核心阻力之一。深层次的不说，宏观的不说，就拿小小的项目而言，Bug的存在就会拖累项目的进度和交付效果。尽管现在很多公司都主张敏捷开发，但实际上就是在Bug的泥泞中强颜欢笑，不见得都落了好！

三、DeBug之路

Bug是人类的认知局限导致的，因此Bug不可避免，DeBug更是不可或缺。即使再高明的程序员，也在所难免。无论是千锤百炼的系统，还是久经沙场的大牛，比的还是Debug的能力。

要Debug，不知Bug怎行？所谓知己知彼，才能百战不殆。裸机时代的程序员，有了问题，除了仔细推敲编码指令外，还得拆卸机器看零件，拿万能表测电路。通用操作系统时代的程序员，有了问题，可以眼观四路，耳听八方，能用的手段多了去。翻日志、查源码、挂调试器、上补丁等网络热议的DebugN段进阶法，自不必赘述。

关键是得认清Bug的时空属性。电子计算机不仅在物理电路的设计上更加成熟，在系统层面也早已是通用操作系统的天下。操作系统的硬件抽象层，就是一个复杂的虚拟机。在这一层面，它将硬件层面的潜在错误（Bug）进行了抽象兜底。而虚拟内存机制，又进一步将硬软件层的潜在Bug进行兜底抽象。这些基础抽象层便是软件Bug的如来手掌心。

所以说，软件的技术Bug其实是有兜底的，只要程序员深入了解这些机制，总能得到解决（DeBug）。但是要了解这些机制，本身因为商业因素，或多或少有些障碍而已。不过常见的Bug，就是那种发现了，也不会有人给赏金的那种，就可以百度没有上谷歌。

技术上的Bug，在系统的加持下，其实是可以穷举的。如果这么说，可能有很多人难以理解，那换成虚拟机来类比，可能就好理解了。大家都知道解释型编程工具，比如JAVA/.NET/VB(VBA)等，它们的源码很容易跨平台。

可是大家伙知道么，解释型语言的鼻祖BASIC，在上世纪70年代初DEC就放弃了传统的编译机制，改为解释机制（也即虚拟机机制）。解释器采用一套类似于RICS指令（简单整齐、速度快），来处理代码逻辑，而解释器本身负责将这套伪指令映射为本机CPU指令。这样，理论上源码依赖解释器就可以在不同类型的机器上运行，从而实现不变应万变。在系统层面，潜在的问题(Bug)，就像解释器的伪指令那样，其实是一个抽象的有限集合。怎么说呢，技术人员能写出的技术Bug，系统已然尽知，人家在设计的时候就摸了个遍！

只可惜BASIC生错了年代，遇到了错的理念。在硬件性能未跟上的背景下，解释机制的低性能始终让人难以容忍，这一点一直持续到二十多年后的VB5.0，最终改回编译机制才算刹住车。当JAVA乘着互联网的春风异军突起时，微软却继续梦想着一统天下的美梦，始终认为跨平台是系统的事，应用跨平台是个伪命题。现在，JAVA已经自造生态，在自家的概念里风生水起，而VB的解释器依然赖在Office的大床上。

软件行业真正的Bug，其实并不在技术上，而在应用领域的认知缺陷上。这样的Bug，没有兜底，就像大航海时代，谁发现谁受益，因而是具有商业价值的。这样的Bug是百度谷歌不到的，即便能也是烂大街的那种。