到底什么是大家口中的“阴间代码”？

如果你经常逛程序员论坛，刷技术类热搜，“阴间代码”这四个字你一定不陌生，不同于我们常规理解的“有bug的代码”，阴间代码指的是逻辑晦涩、毫无规范、注释缺失，甚至只有原作者看得懂，其他人接手直接原地破防的代码——用行话讲，这就是典型的“技术债务”,还是利滚利还不完的那种。

2024年4月份，一个#00后程序员接手8年电商项目破防#的话题冲上了微博热搜，十几万程序员在评论区共情，妥妥的最新时事，发帖的小伙子刚毕业进了一家本地创业公司，第一天上班就被安排维护公司成立之初写的电商系统，打开代码库直接傻了：整个项目没有README文档，没有接口说明，所有变量全是无规律的拼音首字母缩写，yh_sf_3这种变量名随处可见，你根本猜不到是“用户顺丰运费首重”还是“用户三方登录id”，更绝的是，他翻到一段核心逻辑，里面写了一行判断：if(今天是周五 && 登录IP不是老板的IP) {所有16点后的订单发货时间改次日}，整段逻辑只有一句注释：“懂的都懂”。

新来的哪懂这种“职场潜规则代码”？他排查了整整一天，才从老员工嘴里问出来：原来老板周五不想处理售后，要求所有晚班订单统一改到周一发，但老板有时候在公司盯着，又要装成“我们随时发货”的样子，所以当时兼职写代码的产品经理就写了这么一段阴间逻辑，没敢写清楚注释，就留了句“懂的都懂”，小伙子发帖说“第一天上班就想递辞职报告”，底下高赞评论全是同行的血泪史，有人说自己见过变量名从a1排到a128，有人说自己接手的项目里，注释写着“这个bug我不知道为什么会好，反正别改”，还有游戏圈的同行爆料，自己维护一款运营了15年的老端游，打开代码看到一句10年前的注释：“这个功能国庆后改，谁不改谁是狗”，结果他2024年接手的时候,那段逻辑还原封不动躺在哪儿。

我身边就有实打实的例子，大学同学阿凯毕业后进了南方一家老牌车企做IT开发，刚入职就被安排维护一套2008年上线的经销商库存管理系统，原来的负责人已经退休带孙子了，只留了一个硬盘拷代码，阿凯打开代码第一页，第一行注释就是“此代码勿改，改出问题别找我”，当场给他后背整得发凉，后来集团做数字化转型，要把这套系统的数据对接到新的移动端平台，要求两周内完成对接，阿凯看了三天发现一个离谱的问题：所有库存超过1000台的经销商，系统自动会把库存数减10，他翻遍逻辑找不到原因，以为是当年的笔误bug，就顺手改了回来，结果上线第二天对账，整个区域经销商的库存差了五百多台，财务直接炸了，阿凯被领导骂了一下午，没办法只能打电话问退休的老程序员，老程序员慢悠悠地说：“哦那个啊，十年前服务器硬盘只有几十G，每个经销商都多报库存占空间，我就统一给超1000的减10，那时候谁能想到十几年后硬盘能按T算啊？而且这么多年大家都习惯对账自己加10了，你改了可不就错了么。”阿凯说那天他挂了电话，坐在公司楼下抽烟,差点就提离职了。

阴间代码到底是怎么来的？

很多人骂写阴间代码的程序员没素质，其实真不是所有阴间代码都是故意写的，追根溯源,无非是这么几种情况：

第一种最常见：赶工期赶出来的，互联网早年增量时代，跑马圈地比什么都重要，今天产品提需求，明天就要上线抢市场，哪有空给你慢慢写优雅代码？能跑通上线就是胜利，重构？优化？以后再说——然后这个“以后”就永远没有以后，我认识一个做游戏运营开发的朋友阿哲，之前参与过一款老IP手游的重启项目，原来端游的代码是2005年赶版本写的，为了赶公测，一堆功能都是硬凑上去的，比如兑换码功能，原来的开发者直接把所有合法兑换码写死在代码里，每出一批新兑换码就要更一次包，十几年过去，光兑换码相关的代码就堆了几千行，根本没人敢动，重构要花三个月，项目根本等不起，只能带着这个坑接着走,这不就是典型的赶工期赶出来的阴间代码。

第二种就是历史遗留，没人接盘，技术迭代太快了，十年前的技术框架现在没人用了，当年写代码的人要么转行了要么跳槽了，文档没留，交接没做，剩下一堆烂代码给新人，可不就是阴间吗？就像刚才说的车企那个库存系统，老程序员退休了，谁能想到十几年前他为了省硬盘空间改了库存数，这种私人性质的“潜规则”，根本不会写在文档里，还有很多传统行业的内部系统，很多都是当年找外包做的，外包公司都倒闭了，出了问题只能找新人硬啃,啃出来就是一身伤。

第三种就是现在新出来的：AI生成代码养出来的，2024年GitHub做过一个统计，超过70%的程序员已经在用AI辅助写代码，但是有超过40%的AI生成代码没有符合规范的注释，超过20%的AI生成代码带有已知的安全漏洞，很多程序员图省事，AI写完直接复制粘贴跑通，根本不梳理逻辑，不补注释，自己过两个月再看都看不懂，更别说接手的人了，我之前在掘金看到一个帖子，一个实习生用GPT写了一个用户签到功能，跑通了就交了，结果正式上线之后，只要用户是2月29号注册的，每年都领不到签到奖励，翻代码才发现，AI写的日期判断逻辑有问题，又没注释，找这个bug找了整整三天,这不就是新时代的阴间代码？

当然也有故意的：不少老程序员觉得“代码只有我看得懂，我就不会被开除”，故意写得晦涩难懂，不写注释，就是为了提高自己的不可替代性，这种就真的是职业素养问题了，坑别人也坑自己，之前就有个广为流传的段子：一个程序员跳槽去新公司，接手一个老项目，骂了三天里面的阴间代码，结果查git提交记录，发现是自己五年前写的，最后只能默默把骂人的话删掉，改成“此处逻辑待优化”。

阴间代码的坑，从来不止坑程序员

很多人觉得，不就是难维护一点，程序员多加点班就好了，其实根本不是，阴间代码坑的从来不止程序员，一旦出问题,整个公司甚至普通用户都会遭殃。

2024年年初，美国联邦医保系统就因为一段1980年代写的阴间代码出了大事：当年写代码的时候，闰年的日期判断逻辑写得有问题，碰到整百年不闰的规则没处理，这么多年一直没出问题，结果2024年刚好是闰年，一下导致超过10万份医保报销单处理失败，很多普通民众拿不到报销款，闹到了国会，最后政府花了几百万美元，把当年写代码已经82岁的老程序员请出山，修了整整一周才把问题解决,你说这成本高不高？

放到游戏圈也一样，我之前听说过一个事，国内一家做传奇类页游的公司，原来的老代码里面有一段阴间逻辑：只要玩家充值金额超过10万，就自动把玩家的爆率调到最高，原来写代码的人是为了讨好大老板留下的后门，没写注释，他走了之后没人知道，后来合区改数据，把这个逻辑带到了新服，结果开服第一天就有大玩家打出了一堆顶级装备，整个服务器的经济系统直接崩了，最后不得不关服回档，损失了几百万的流水,这个就是阴间代码捅出来的大娄子。

回到互联网行业，刚才说我同学阿凯那件事，就因为改了那一行阴间代码，整个项目上线推迟了半个月，整个项目组十多个人的季度奖全部打八折，所有人都跟着受连累，更不用提那些因为阴间代码留的后门，被黑客入侵拖库，导致用户信息泄露的事故了，很多安全问题追根溯源,都是一段没人维护的阴间代码留下的漏洞。

我们真的能消灭阴间代码吗？

聊到这里，很多人会说，那我们定好规范，做好代码评审，不就能消灭阴间代码了吗？其实我个人觉得，完全消灭阴间代码是不可能的，因为总有赶需求的时候，总有紧急改bug的时候，偶尔留一点技术债务是不可避免的，但我们可以少留，甚至不故意留坑,这其实是一个程序员最基本的职业素养。

我之前和字节的一个开发朋友聊天，他说他们团队不管业务多忙，每个季度都会留10%的时间给团队做技术债务偿还，抽那些维护了好几年的老代码出来重构，补文档补注释，每个Pull Request必须过代码评审，没有注释的代码根本合并不进去，所以他们团队很少出现那种让人破防的阴间代码，现在整个互联网从增量时代进入存量时代，都在讲降本增效，其实最大的增效就是减少技术债务，一段阴间代码，改一个功能要花一周，而整洁规范的代码可能一天就改完了,这里省下的就是真金白银的人力成本。

对于现在用AI写代码的程序员，我也想说一句：AI给你的代码，一定要自己梳理一遍逻辑，补好注释，别图省事直接用，你现在省的十分钟，可能就是以后接手的人几天的工作量，真犯不上，很多人说“我走之后哪管洪水滔天”，但其实圈子就这么大，保不齐你哪天换工作，就接手了自己当年留下的阴间代码,到时候哭都来不及。

说白了，阴间代码本质上就是一个行业的“沉疴”，它不是什么大奸大恶的东西，但就是一点点消耗着整个行业的效率，消耗着程序员的热情，多写一句注释，多留一份文档，少故意写一段让人看不懂的代码，其实就是给同行留路，也是给自己留路，毕竟谁也不想上班第一天打开代码，就看到一句“此代码勿改，改出问题别找我”,对吧？