领导
如果你参与过大型项目的开发，就会明白所谓屎山代码有多么令人头疼。没人能确切知道某段代码会以何种方式对整个项目产生影响。曾经我也遇到过一件特别恶心的事情：经过详细排查，我确信某个文件夹中的代码完全无用，于是果断将它删除。当时我信心满满，认为这些代码肯定不会被用到，因为里面存在明显的语法错误。如果它们真的运行过，编译阶段必然会出现错误提示，但事实是之前的编译过程一直顺利进行。然而，删掉这个文件夹后，事情却变得诡异起来——编译竟然无法通过了，而且报错的位置看起来与那个被删除的文件夹毫无关联。这让我非常困惑，花了整整两周时间，仔细研究了规模达40万行的代码库，最终才找到问题所在。原来，编译流程本身存在漏洞，由于那个文件夹里的代码包含语法错误，导致涉及它的某个编译步骤提前结束，恰好避开了脚本中有缺陷的部分。而为什么那一步没有报错？因为前人在这段脚本中添加了一个||exit 0的命令，无论发生什么情况都会强制让脚本返回成功状态。如今，这座屎山依然归我负责，毕竟我已经是最了解它的人了。
领导说，我花了两周时间深入研究，现在已经成为
公司的重要资产，就像这个项目的守护精灵（daemon），必须长期维护它。后来，我还是决定把那个文件夹彻底删除，但鉴于编译脚本过于复杂，懒得再去分析细节。于是，我直接创建了一个名为fuck.c的文件，在其中用字符画了一根中指。这个文件显然不是合法代码，但它同样可以制造编译错误，后续效果和之前如出一辙。有时候你会发现，某些语法错误竟然是项目能够成功编译的必要条件。总结来说，之所以不删除那些看似无用的代码，主要是因为删除它们可能会带来额外的人力成本，并且谁也无法预测可能引发的连锁反应，也就是所谓的蝴蝶效应。而保留这些代码，顶多占用一些存储空间和流量，对整体影响不大，甚至还能留给用户或玩家去探索，说不定还能收获意想不到的效果。
