一位Oracle程序员在Hacker News上吐槽自己的工作，引起了热议，内容如下：

Oracle数据库12.2。它有近2500万行C代码。

这实在太恐怖了，简直难以想象！你做不到在不破坏成千上万个现有测试的情况下更改产品中的单单一行代码。好几代程序员在很紧的项目期限内编写了这些代码，代码中充斥着各种各样的垃圾内容。

非常复杂的逻辑、内存管理和上下文切换等等，一切都用数千个标志（flag）连接起来。整个代码充斥着神秘的宏命令，要是不掏出笔记本，手动展开宏命令的相关部分，你就无法搞清楚这些宏命令。可能要花一两天才能真正搞明白某个宏命令的作用

有时你需要搞明白20个不同标志的值和效果，以预测代码在不同的情况下会如何运行。有时多达数百个标志！我一点也不夸张。

这个产品仍然存活并仍然可以用的唯一原因是数百万次的测试！

下面是Oracle数据库开发人员平常的一天：

开始处理一个新的bug。

花两周的时间试图搞清楚20个不同的标志，这些标志以神秘的方式相互交互、导致这个困境。

再添加一个标志以处理新的特殊场景。再添加几行代码来检查该标志，避开有问题的情况，并避免该bug。

将更改提交到含有大约100台到200台服务器的测试服务器集群，这些服务器将编译代码，构建新的Oracle数据库，并以分布式方式运行数百万个测试。

下班回家。第二天来上班，处理别的bug。测试可能需要20小时到30小时才能完成。

下班回家。第二天来上班，检查你的服务器集群测试结果。顺利的话，会有大约100个失败的测试。倒霉的话，会有大约1000个失败的测试。随机选择一些测试，并试图搞清楚你的假设出了什么问题。也许另有10来个标志要考虑，才能真正搞清楚bug的本质。

再添加几个标志，试图解决问题。再次提交变更进行测试。再等20小时到30小时。

另外重复冲洗两周，直到你确保神秘的标志组合无误。

终有一天你会成功，没有一次测试失败。

添加针对你更改的100多个测试，确保下一个不幸接触这段新代码的开发人员永远不会破坏你的修复程序。

为最后一轮测试提交工作。然后提交以供审查。审查本身可能另外需要2周到2个月。所以现在改而搞下一个bug。

2周到2个月后，一切都已完成，代码最终合并到主分支中。

以上就是在Oracle修复bug的程序员日常工作的客观描述，一点也不夸张。现在想象一下开发新功能会有多么恐怖。开发一项小小的功能就需要一年半载（有时甚至长达两年！）（比如说添加一种新的身份验证模式，比如支持AD身份验证）。

这款产品可以用这本身简直就是个奇迹！

我不再为Oracle工作了。永远不会再为Oracle工作了！