更多有趣的科普，欢迎点击右上角关注我↗通常说，一个人造的、很庞大的事物，会给人很厉害的感觉。比如说摩天大楼⬇️或者巨型水坝⬇️看着这种东西，世超不禁想到这几个字： “ 人类工程学奇迹 ” 。但是欣赏归欣赏，这种巨型工程项目如果出了啥子问题，不得不维护的话，那这个维护痛苦程度只能用 “ 灾难 ” 来形容了。世超最近在网上就看到了这样一个科技界的庞然大物： Oracle Database 12.2 的代码库！在国外计算机论坛 Hacker News 上，有人问了这样一个问题： “ 你见过的规模最大的还在使用的烂代码有多大？ ”一个目测是 Oracle 员工， ID 叫 “ oraguy ” 的用户给出了回答⬇️甲骨文数据库 12.2 版本，一个将近 2500 万行 C 语言代码的庞然大物！世超打个比方吧，写代码就好比堆积木，一旦整个积木都有了功能之后，随便动其中任何一块，都会导致其他积木出事儿，塌了都有可能。。。这样巨型项目经手的程序员太多了，每个人都按照自己的方式解决问题，这就导致其他人要在项目之上写东西的时候，得花大量时间搞懂原来的代码是怎么运作的。。。好在这个代码库还有非常完整的测试代码，出了问题不用让程序员自己找 BUG 出处。只不过。。。据 oraguy 说，这个项目改一行代码之后，一般会跳出 1000 多条测试失败的消息，然后程序员要一个个排除。。。也亏得这上百万项测试，这个项目现在还能商用。所以给 Oracle Database 写代码的程序员，工作流程一般是这样的⬇️1. 拿到一个新任务：解决一个新发现的 bug 。2. 花两周时间了解 20 个不同的 flag （ 标记 ），这些标记用一种很奇怪的方式制造了这个 bug 。3. 尝试添加 flag，写几行代码，同时要小心不会制造出更多 bug4. 提交一下修改过的代码，然后用测试服务器创造一个新的数据库，并且跑一下那几百万个测试。。。5. 回家，第二天来的时候做点儿别的，因为测试要跑二三十个小时。6. 回家，第二天来的时候看看结果：运气好的话可能只有 100 个测试失败；运气不好的话有 1000 个失败。随便找个失败的测试，理解一下这个 bug 的原理。7. 改一改，提交，测试，再来二三十个小时。。。8. 重复以上步骤，俩星期后你大概能理解这个 bug 的原因了。9. 终于，在你几乎锤蛋自尽之前，发现某次测试完全通过了！10. 再写上百个测试，以防下次哪个晦气孩子要碰项目的时候，不会把你的修改搞砸。。。11. 提交代码，做最后一次测试和代码复盘，这个过程大约需要花 2 周到 2 个月，所以这段时间去修别的 bug 吧！12. 搞定一切，代码修改可以添加到产品里去了！以上。。。。而且据 oraguy 说，如果要给数据库添加一个小功能，往往需要花 6 个月到 1 年的时间。原因世超想想都知道：可能写新功能代码只用花 1 个月，剩下的时间都在改因为新功能产生的 bug 。。。还记得差评君之前说的技术债么？ Oracle 的这个 2500 万行的项目，可能就是负债累累的样子。。。会变成这样的原因。。。就是每个人干活都没啥规范，碰到问题修修补补就好，完全没有考虑整个项目。事实上，如果遵守一些代码规范的话，就不会这么糟糕。世超的同事里有个前华为员工，说他们组的大项目也有上千万行代码，修改 bug 或者添加功能的周期只有数周。所以说。。灾难可能都是遭难的人当初一手造出来的。。。图片来源：Construction SpecifierTravel NevadaDrupal Integrationcodeshipg2techgroup参考资料： Ask HN: What's the largest amount of bad code you have ever seen work?“ 25,000,000 行的代码就问你敢不敢动？！” - CSDN的文章 - 知乎“ 为什么感觉这工作听起来很清闲的样子。。。 ”

更多有趣的科普，欢迎点击右上角关注我↗

通常说，一个人造的、很庞大的事物，会给人很厉害的感觉。

比如说摩天大楼⬇️

或者巨型水坝⬇️

看着这种东西，世超不禁想到这几个字： “ 人类工程学奇迹 ” 。

但是欣赏归欣赏，这种巨型工程项目如果出了啥子问题，不得不维护的话，那这个维护痛苦程度只能用 “ 灾难 ” 来形容了。

世超最近在网上就看到了这样一个科技界的庞然大物： Oracle Database 12.2 的代码库！

在国外计算机论坛 Hacker News 上，有人问了这样一个问题： “ 你见过的规模最大的还在使用的烂代码有多大？ ”

一个目测是 Oracle 员工， ID 叫 “ oraguy ” 的用户给出了回答⬇️

甲骨文数据库 12.2 版本，一个将近 2500 万行 C 语言代码的庞然大物！

世超打个比方吧，写代码就好比堆积木，一旦整个积木都有了功能之后，随便动其中任何一块，都会导致其他积木出事儿，塌了都有可能。。。

这样巨型项目经手的程序员太多了，每个人都按照自己的方式解决问题，这就导致其他人要在项目之上写东西的时候，得花大量时间搞懂原来的代码是怎么运作的。。。

好在这个代码库还有非常完整的测试代码，出了问题不用让程序员自己找 BUG 出处。

只不过。。。据 oraguy 说，这个项目改一行代码之后，一般会跳出 1000 多条测试失败的消息，然后程序员要一个个排除。。。

也亏得这上百万项测试，这个项目现在还能商用。

所以给 Oracle Database 写代码的程序员，工作流程一般是这样的⬇️

1. 拿到一个新任务：解决一个新发现的 bug 。

2. 花两周时间了解 20 个不同的 flag （ 标记 ），这些标记用一种很奇怪的方式制造了这个 bug 。

3. 尝试添加 flag，写几行代码，同时要小心不会制造出更多 bug

4. 提交一下修改过的代码，然后用测试服务器创造一个新的数据库，并且跑一下那几百万个测试。。。

5. 回家，第二天来的时候做点儿别的，因为测试要跑二三十个小时。

6. 回家，第二天来的时候看看结果：运气好的话可能只有 100 个测试失败；运气不好的话有 1000 个失败。随便找个失败的测试，理解一下这个 bug 的原理。

7. 改一改，提交，测试，再来二三十个小时。。。

8. 重复以上步骤，俩星期后你大概能理解这个 bug 的原因了。

9. 终于，在你几乎锤蛋自尽之前，发现某次测试完全通过了！

10. 再写上百个测试，以防下次哪个晦气孩子要碰项目的时候，不会把你的修改搞砸。。。

11. 提交代码，做最后一次测试和代码复盘，这个过程大约需要花 2 周到 2 个月，所以这段时间去修别的 bug 吧！

12. 搞定一切，代码修改可以添加到产品里去了！

以上。。。。

而且据 oraguy 说，如果要给数据库添加一个小功能，往往需要花 6 个月到 1 年的时间。

原因世超想想都知道：可能写新功能代码只用花 1 个月，剩下的时间都在改因为新功能产生的 bug 。。。

还记得差评君之前说的技术债么？ Oracle 的这个 2500 万行的项目，可能就是负债累累的样子。。。

会变成这样的原因。。。就是每个人干活都没啥规范，碰到问题修修补补就好，完全没有考虑整个项目。

事实上，如果遵守一些代码规范的话，就不会这么糟糕。

世超的同事里有个前华为员工，说他们组的大项目也有上千万行代码，修改 bug 或者添加功能的周期只有数周。

所以说。。灾难可能都是遭难的人当初一手造出来的。。。

“ 为什么感觉这工作听起来很清闲的样子。。。 ”

未经允许不得转载：博客 » 新开奇迹sfbug教程(给2500万行代码修复bug的程序员都怎么上班？)