程序员为什么要一直写bug ，不能一次性写好吗？

点击上方蓝字设为星标

下面开始今天的学习～

2020 年到来以后，全世界不同地方的软件系统，出现了一些 bug。

纽约街边的停车收款机，突然从 2020 年的第一天开始，不能正常接收信用卡支付了。

这使得人们只能使用硬币或者纽约市的专属停车收费 app：ParkNYC 进行付款。但是，都 2020 年了，很少有人会随身携带一堆硬币。至于这个停车收费 app，因为必须要预先存进去 25 美元才可以使用，引来了很多人，尤其是游客的不满。

一时间，纽约市怨声载道。现在，纽约的交通部正在抓紧处理这个问题，然而，他们需要为整个城市的近 14000 个停车收款机升级软件程序。

波兰的一家公司 Novitus，在 2020 年来临的第一天，所有的收银机，都不能正常地打印票据了。如今，公司也正在紧急地修复这个问题。

一款著名的拳击类游戏：WWE 2k20，在 2020 年的第一天，突然无法正常运行了。然而，如果用户把系统时间修改为 2020 年以前的任何一天，游戏都能正常运行。

德国汉堡市的地铁，在新年来临的第一天，延误了一段时间。据报道是因为一次软件升级失败导致的。大概率的，这次升级失败，也是因为时间走到了 2020 年。

splunk 是一家硅谷的创业公司，专门分析服务器产生的数据，从而快速完成业务分析、安全事件审计、DDoS 攻击监控等等服务。2019 年 11 月，splunk 发现自己的软件系统在 2020 年到来的时候，将无法正常运作。所以，splunk 强制他的所有客户——包括美国前 100 强企业的 92 家，来升级系统，以避免这一“灾难”。

---

为什么有那么多软件系统在 2020 年到来的时候，会产生 bug？这个问题，和本世纪初的千年虫 bug 的原理，是一模一样的。

所谓的千年虫 bug，是指当时间走到 2000 年的时候，很多软件系统会崩溃。

为什么时间走到 2000 年的时候，软件系统会崩溃？因为在很多软件系统中，年份是使用两位数字来存储的。

如果是 98，或者 99，我们可以很安全地认为，时间是 1998 年或者 1999 年，规则就是在这两位数字前面加上 19。但是，对于 00，加上 19，就是 1900 年，而不是 2000 年。于是，时间发生了错误，整个软件系统将不能正常运转。

工程师们很早就意识到了千年虫 bug 的存在，于是，在新世纪来临之前，各个软件公司都在全力解决这一问题。甚至，在那个年代，有一个专门的职位，叫“千年虫工程师”，顾名思义，就是专门解决千年虫问题的。

在当年，千年虫工程师是平均薪资最高的工程师。据报道，和千年虫相关的“修补”工作，大约造成了全世界 3000 亿到 5000 亿美元的损失。

讽刺的是，在 2000 年以后，千年虫工程师这个职位都不复存在了。

---

时间来到今天，2020 年之所以会发生这一系列的 bug，和千年虫的原理一样：系统使用两位数字存储年份。

但这一回，对于这些软件系统，18 或者 19 可以被系统正确地认为是 2018 年或者 2019 年。不过，当时间走到了 20，系统懵逼了，会误以为是 1920 年。

为什么？因为 1920 年，是很多系统的“标定年”，英文叫做 pivot year。也就是系统会自动在 00 到 19 这些年分之前加上 20，表示 21 世纪的年份；而会给 20 到 99 这些年份之前加上 19，表示 20 世纪的年份。

为什么会将 1920 年作为“标定年”？这又牵扯到一段计算机科学的历史。

熟悉“时间戳”的同学都知道，UNIX 系统定义起始时间为 1970 年 1 月 1 日 0 时 0 分 0 秒。所以，这个时间是 UNIX 世界的起始时间。

随着 UNIX 在服务端的普及和流行，这个起始时间甚至超越了 UNIX 系统，成为了整个计算机世界的起始时间。就算没有接触过 UNIX 的同学，无论是在数据库中，还是在各个语言的时间戳转换的函数中，都应该接触过这个“知识点”：0 这个时间戳，表示 1970 年 1 月 1 日 0 时 0 分 0 秒。

这也解释了为什么大家在处理和时间相关的程序的时候，有的时候，一不小心，显示的时间是 1970 年 1 月 1 日 0 时 0 分 0 秒。如果在国内的同学，可能会经常看到 1970 年 1 月 1 日 08:00。这是因为，UNIX 定义的起点时间，是以格林威治时间为准的。而由于中国时间以北京时间为准，而北京在东八区，所以，对应 UNIX 起点时间，就是 1970 年 1 月 1 日 08:00。

这和 1920 年有什么关系？答案是，1970 年前后各取 50 年，就是 1920 和 2020 年。所以，很多计算机系统都以 1920 年作为“标定年”，来转化两位数字表示的年份。而这种转换，到了 2020 年，就失败了。

---

2020 年 bug 的一个简单解决方案，就是使用四位数字，而非两位数字来表示年份。这么简单的一个方案，为什么当时不采用？

答案是，如果回头看 20 年前，甚至 30 年前的计算机系统，存储空间还是极度紧张的。100 以内的两位数字，只需要一个字节就可以表示；而 4 位数字，则需要两个字节，整整多了一倍。

这个存储空间的差距，现在看起来简直不值一提。但是，在二三十年前，事情可完全不一样。

我是 1998 年拥有的第一台个人电脑的，那个时候的硬盘容量，我印象很清楚，只有 512 MB，还算高配了。而那时的主要移动存储介质，是一种叫做软盘的介质。每片软盘，只能存储 1.44 MB 的内容。

1998 年尚且如此，更不用提 1990 年了。而个人电脑处理的数据和资料毕竟有限。如果是服务器，每天处理成千上万的数据，在时间存储上，使用两位数而非四位数，绝对是一个重要的优化。如果大家能找到那个年代的服务器开发教程，甚至会特意强调这个优化。

然而，这个曾经的优化，如今成为了 bug 的源泉。

另一个重要原因，在于很多人并不认为某个程序或者某段代码能运行 20 年，30 年之久。甚至，多数人不认为自己写的程序能运行 5 年时间。

虽然，在大多数情况下，这个结论是正确的。软件发展的速度出奇的快，大多数代码很快就会淘汰掉。但是，仍然有少部分代码，坚强地一直运行着。

而且，每一个软件工程的开发，并非都是从 0 开始的。以 MacOS 系统为例，我们看其中的 API 命名，包括部分框架的设计模式，就能明白这其中包含着多少遗留的历史代码了。

所以，即使某一个软件产品退出了历史舞台，但是其中的代码片段，很有可能继续以一种不为大众所知的方式，存在于现代世界中。这些代码片段中的 bug，好像从“远古时期”乘坐时间机器来到今天，成为当下的安全隐患。

有意思的是：这种事情能完全避免吗？答案是不能的。

因为，这样的 bug，本质不是逻辑错误，而是假设错误。然而，这样的假设错误，站在当年的视角看，不仅不是错误，甚至可以叫做是“优化”。

可是，短短 20 年，这就变成了一个错误。

这就好比，如今，我们不可能选择使用五位数去存储年份一样。然而，到了 9999 年，这将成为一个大问题。

这件事非常好地向我们阐述了软件工程的复杂性。软件工程本身不是绝对的数学公式推导。在软件工程的很多实现方案中，是没有绝对的“对”和“错”的，而是具有相应的时代特点的。

然而，在一个时代中，绝对正确的事情，到了另一个时代，很有可能是存疑，甚至是绝对错误的。

这样的事情，在人类的文明历史中，时常发生。比如封建君主制，比如希特勒，比如冷战思维。如今，这样的事情，也发生在了软件的世界中。

这说明了什么？

软件本身，已经毫无疑问地，成为了人类文明的一种体现形式。和书籍，音乐，电影，雕塑，等等等等，是一样。

而软件工程师，则是这种人类文明体现的书写者。

嗯，反正我就是这么“骗”自己的：）

大家加油！

---