屎山：垃圾代码是谁写的原创

有个段子说，项目是一座很大的石山。你见过的最大的山？每次想修正一个bug，就要爬到死山的正中心。这句话据说是亚马逊的工程师说的。很多项目都有这个问题，那到底是谁干的？这是谁干的，谁干的？这是什么意思？谁不是我，不是我，你让我收拾干净的。都把手伸出来。李叔，算了，不说了。你说。不要怕。我说那个，他可是怕那帽子再被风吹走，我动你是好了，你说东西，我问问你是谁，那我可不知道。

这是一个真实的故事。有一天上班，小蔡同学大声质问，谁写的垃圾代码？这么明显的bug还不写注释？大家心惊胆战，不敢吭声。经理说，查提交记录，全公司通报，扣得奖金。小戴同学自告奋勇。正在查。过了几分钟。没有动静了，大家围过去一看。小蔡同学说。不可能吧，是我自己一年前提交的。这是网上曝光的一段代码。第一位同学写到最后，请删除这些无用的注释。第二位同学又加了一行，我偏不删。这种无用的代码不会导致什么实质性的危害，但它说明了一个问题。代码未经过人工评审，那更多的垃圾代码都可能会出现。这是某个国产科研项目的代码。大伙发现拉代码怎么这么慢呀？

小蔡同学说。我提交了价包。这种做法不止导致代码库变大，还导致第三方漏洞无法被征集修复。按照正规做法，依赖包是通过网络仓库自动安装的。经常升级才可靠。这段代码大伙都看不懂，问一和二是什么意思？怎么不写注释？小柴同学回答。大神说优秀的代码不用写注释。稍等，我回忆一下一和二的含义。这种代码犯了一个错误，魔法数字。正确的写法是常量。可以看到右边这段代码，不用写注释，大家一看也都能明白。这段代码只是个数据库，账号配置能有什么问题？那么来部署一下事实。产品说测试环境验收通过。把这个包部署到生产环境。小夏同学说不行，要改配置，重新打包。

产品同学说重新打的包，未经过测试环境不能上线。这种错误叫做hard cold写死。正确的写法是环境变量。代码里不要显示任何配置，只打一个包。在测试环境、生产环境引入不同的环境变量即可。某知名游戏加载需要20分钟，非常卡顿，持续了七年，终于有一位拉脱维亚的黑客忍无可忍。使用破解工具发现，游戏加载时，每取一个商品都要逐行读取一个十兆的63000多行的节省文件。最终，If判断了19.8亿次。这种低级的性能翻车发生在知名大厂。说明他们很可能缺乏代码评审机制。很多老项目里都有这种代码。本来有个get方法。

后面接手的人发现想改，但是怕影响别的地方调用，于是复制了一份叫GET1。后面再有人改复制一份叫GET2。最终这个代码就彻底的烂掉了。甚至把整个文件复制一份，比如有一个user类，我复制一个叫USER1。还有一些质量问题，知道的人更少。比如圈复杂度高。函数超过100行内超过1000行。还有右边这种乱写提交信息。多人协作开发的时候，会面临更多的问题。比如风格不统一。有的人喜欢用两个空格，有的人喜欢四个空格或者table。有的人喜欢驼峰，有的人喜欢羊肉串，有的人喜欢下划线。还有就是多人一起提交的一个分支，会导致分支冲突。如果缺乏开发规范，项目很容易出现垃圾代码。

然后大家一看，反正已经烂掉了，再加点垃圾也没关系。这就是破窗户效应。它属于犯罪心理学。1982年发表的原文说。如果窗户被打破并且没有修理，其他的窗户很快就会被打破。