Oracle 数据库 12.2，它有近 2500 万行 C 代码。 这有多恐怖，简直难以想象！你无法在不破坏成千上万个现有测试的情况下更改产品中的单行代码。好几代程序员在有限的项目期限内编写了这些代码，其中充斥着大量的垃圾代码。 非常复杂的逻辑、内存管理、上下文切换等，这些都用数千个 flag 连接起来。整个代码充斥着神秘的宏命令，如果不拿出笔记本，并且手动去展开相关的宏命令，就无法理清楚这些命令。甚至可能需要一两天才能真正理解某个宏命令的作用。 有时你需要理顺 20 个不同 flag 的值和效果来预测代码在不同情况下的行为方式，有时多达数百个 flag ！这一点也不夸张。 这个产品仍然存活并且仍然可用的唯一原因是数百万次的测试！ 以下是 Oracle 数据库开发人员的日常： 开始处理一个新的 bug 。 花两周的时间试图理解 20 个不同的 flag ，这些 flag 以神秘的方式相互交互，导致这个困境。 再添加一个 flag 来处理新的特殊场景。添加几行代码来检查此 flag ，并解决有问题的情况，规避该 bug 。 将更改提交到包含大约100-200台服务器的测试服务器集群，这些服务器将编译代码，构建新的 Oracle 数据库，并以分布式方式运行数百万个测试。 回家。第二天来上班，继续处理别的 bug，测试可能需要20-30个小时才能完成。 再回家，再来上班，检查你的集群测试结果。顺利的话，会有大约100个失败的测试；倒霉的话，将有大约1000个失败的测试。随机选择一些测试并试图搞清楚你的假设出了什么问题，或许还需要考虑10多个 flag 才能真正理解 bug 的本质。 再添加一些 flag 以尝试解决问题，再次提交更改以进行测试，再等20-30个小时。 来来回回重复两周，直到你得到了将这些 flag 组合起来的“神秘咒语”。 终有一天，你会成功，不再出现测试失败。 为你的新更改添加100多个测试，以确保下一个不幸接触这段新代码的开发人员永远不会破坏你的修复。 提交最后一轮测试的成果，然后提交以供审核。审查本身可能还需要2周到2个月，所以现在继续去处理下一个 bug 。 在2周到2个月之后，一切已就绪，代码将最终合并到主分支中。 以上就是对在 Oracle 修复 bug 的程序员日常生活的描述，一点也不夸张。现在想象一下开发新功能会有多么恐怖。开发一个小功能需要6个月到1年的时间。