Bug的渊源软件的故事，你知道吗？！

一、bug的由来

软件 bug 的故事早在二战就开始了，当时还是指针和 bug 之间的事情。程序员和Bug，从Hobo女士开始，是一对敌人。这是错误和调试。从那时起，Bug 和 DeBug 就成了程序员的日常。它不仅显示了人类认知的局限性，也印证了人类在认知上的努力。

随着程序员职业的繁荣，这个职业内部已经分化出更多的细分领域。前端和后端，开发工程师和测试工程师虚拟机上可以编程吗，在外行眼里都是IT工程师。就像金融行业的会计、出纳和总账一样，外行被称为会计师，认为会计就是计算账目和管理资金。

事实上，他们履行各自的职责并最大限度地发挥各自专业知识的效率。只是在业界，有人写bug，有人调试。所以有人开玩笑说：要么写bug，要么在写bug的路上。不在调试中，也不在调试路上。

二、错误的危险

当错误是真正的错误时，它会导致指针电路短路，从而破坏机器。因此，错误从一开始就是预期的破坏者。尽管现代软件中的错误很少会导致硬件损坏，但其后果仍然是压倒性的。

一方面，正如 John Kemeny（曼哈顿计划的参与者和 BASIC 的创建者）评估电子计算机对人类的影响，人类越来越依赖电子计算机。如果程序中的错误导致错误的结果，而人类相信这些错误的结果，后果将是灾难性的。许多航空航天事故和海上事故都是例子，更不用说当前的人工智能应用了。

另一方面，Bug 已经成为软件行业的核心阻力之一。不谈深层次，不谈宏观层面，就小项目而言，Bug的存在会拖累项目的进度和交付效果。虽然现在很多公司都提倡敏捷开发，但其实他们是被迫在bug的泥潭里一笑了之，缺的全没了！

三、调试之路

Bug 是人类认知局限造成的，所以 Bug 是不可避免的，而 DeBug 更是不可或缺。即使是最优秀的程序员也是不可避免的。无论是训练有素的系统还是久经沙场的公牛，都是调试能力。

我想调试，但我不知道如何修复错误？知己知彼，方能百战百胜。裸机时代的程序员遇到问题时，除了要仔细检查编码指令外，还要拆机看零件，用万能表测试电路。通用操作系统时代的程序员，如果遇到问题，可以看四面八方，听四面八方，有更多的使用手段。DebugN阶段的高级方法就不用多说了，网上热议的翻日志、查源码、安装调试器、打补丁等。

关键是识别错误的时间和空间属性。电子计算机不仅在物理电路的设计上更加成熟，而且在系统层面上早已是通用操作系统的天下。操作系统的硬件抽象层是一个复杂的虚拟机。在这个层面，它在硬件层面抽象出潜在的错误（Bug）。虚拟内存机制进一步抽象了硬件和软件层的潜在错误。这些基本的抽象层是软件错误如来之手。

所以，软件的技术漏洞其实是有底线的。只要程序员对这些机制有深入的了解，总能解决（DeBug）。但要理解这些机制，或多或少都存在商业因素的障碍。但是常见的bug是被发现的，没有人赏金的，所以百度不会上google。

技术漏洞，在系统的支持下，其实是可以穷尽的。如果这么说，可能很多人都难以理解，如果用虚拟机来比喻的话，可能会更容易理解。我们都知道解释型编程工具，比如JAVA/.NET/VB（VBA）等，它们的源代码很容易跨平台。

但是你知道吗，解释型语言的鼻祖 BASIC 在 1970 年代初期抛弃了传统的编译机制，改为解释机制（即虚拟机机制）。解释器使用一组类似 RICS 的指令（简单、整洁、快速）来处理代码逻辑，而解释器本身负责将这组伪指令映射到本机 CPU 指令。这样，理论上源代码依赖解释器运行在不同类型的机器上，从而实现不断的变化。在系统级别，潜在的问题（错误），如解释器指令，实际上是一组有限的抽象。怎么说呢，技术人员能写的技术bug，系统已经知道了，

可惜BASIC生错时代，遇到了错误的概念。在硬件性能跟不上的背景下，解释机制的低性能一直让人难以忍受，而且这种情况一直持续到20多年后的VB5.0，只有当编译机制终于改回来了。留在车里。当JAVA乘着互联网的春风，微软继续梦想称霸世界的梦想。它一直认为跨平台是系统的东西，跨平台应用是个伪命题。现在，JAVA已经创建了自己的生态，在自己的理念中蓬勃发展，而VB的解释器仍然依赖Office的大床。

然而，软件行业真正的bug不在技术上，而在应用领域的认知缺陷。这样的虫子是没有底线的，就像大航海时代一样，谁找谁受益，就具有商业价值。所以，这样的bug，是百度和谷歌之外的，就算可以，也是烂大街的那种。

欢迎关注BtOfficer（收藏、点赞、关注+转发），更多精彩还在继续（专栏会更系统全面虚拟机上可以编程吗，但需要你的支持），有认真技术，有轻松闲聊，期待您的加入！