甲骨文 2500 万行的屎山代码有多“恐怖”？

【导读】：2018 年 Hacker News 上一篇对 Oracle 屎山代码的吐槽帖子，@宝玉XP 老师最近翻译了，转过来大家一起看看。

Oracle 数据库 12.2 版本竟然包含了将近 2500 万行的 C 语言代码。

想想都觉得可怕！在这个产品里，改动哪怕一行代码，都有可能导致成千上万的测试失败。历经数代程序员在紧迫的截止日期中辛勤编写，结果却是代码变得杂乱无章。

Oracle 中复杂的逻辑、内存管理、上下文切换等功能，竟然是靠成千上万个标志 (flags) 来维系的。整个代码中充斥着神秘的宏，要理解这些宏的含义，常常需要亲手扩展、一天甚至两天的时间去研究。

有时候，为了预测代码在不同情境下的表现，你需要理解多达 20 个甚至 100 个不同的标志值及其影响。我这可不是夸张。

这个产品之所以还能运行，全靠着无数的测试！

Oracle 数据库开发者的日常是这样的：

• 开始修复一个新的 bug。

• 花上两周时间去弄懂那 20 个相互作用神秘的标志，这些标志造成了 bug。

• 为了应对新的特殊情况，增加一个新标志。再写几行代码，检查这个标志，尽量绕过问题，避免 bug。

• 把修改提交到一个由 100 至 200 台服务器组成的测试农场。这些服务器会编译代码，构建新的 Oracle 数据库，并分布式地运行数百万个测试。

• 回家，第二天再来处理其他事务。测试可能要跑 20 到 30 小时。

• 回家，第二天再来查看测试结果。运气好的时候，大约有 100 个测试失败。运气差时，可能有 1000 个。随机挑选几个测试，试图理解你的假设出了什么错。可能还得考虑另外大约 10 个标志，才能真正弄明白 bug 的本质。

• 为了解决问题，增加一些新的标志，再次提交测试。又等 20 到 30 小时。

• 接下来的两周，不断重复这个过程，直到找到正确的标志组合。

• 终于有一天，你成功了，没有一个测试失败。

• 为你的更改新增上百个测试，以确保下一个不幸碰到这段代码的开发者不会破坏你的成果。

• 为最终版本的测试提交工作，然后提交审查。审查过程可能又要花费 2 周到 2 个月。与此同时，继续修复下一个 bug。

• 两周到两个月后，一切完成后，你的代码终于能合并到主分支了。

以上是 Oracle 程序员修复 bug 的真实写照。想象一下开发新功能得有多艰难。开发一个小功能，比如增加新的认证方式（例如对 AD 认证的支持），竟然需要半年到一年，有时甚至两年！

这个产品居然还能运行，真是个奇迹！

我已经不在 Oracle 工作了，以后也不会再回去了！

网友评论

@Espressopaws: Oracle 原北京研究院的家伙就是天天这样修 bug 的。话说近千个 if-else，再快的 CPU 都快不起来，竟然还能运行。以前老板碰到 20 多个 if-else 嵌套在一起都受不了，在一次酒后吐言对这样的程序员 “绝望”，后来这哥们非常识趣地主动离职了。

@用户5400427920: 能测试和验证已经是业界顶流了，我们接手我司一个项目的工程化，从项目 25 万行里清理删除了 15 万行死代码，期间还有算法给死代码里加实验，发问，答复：“这块代码的 keyword 和他接到任务的 keyword 相同，所以就在这加了”。在我们接手前这个项目已经稀里糊涂迭代两年了

@tombkeeper: 我早年研究过一次 Oracle 的漏洞，后来再也不搞了。逆向 Oracle 的感觉就像在热带雨林里找一只青蛙，然后通过控制丢虫子的位置和节奏让青蛙跳桑巴舞。

@一切皆有可萌：更悲催的是，1900 年判定为闰年这个错误，甚至不是 Excel 的，而是更早的一款电子表格软件 lotus-1-2-3 的。但是微软为了占领电子表格软件的市场，必须要兼容 lotus-1-2-3 的文档格式，结果就必须把它的 bug 也兼容进来。

@老张评论：著名的化学工程模拟软件 aspenplus，核心代码是创业者当年读博士时熬夜的 fortran 代码。估计后来他自己也看不完全明白。谁也不敢动。再谁也不明白核心的基础上开发，可不是就是穷举一切可能。

原贴：https://weibo.com/1727858283/NuM5LyWWq