上周五晚上十一点，何删我盯着屏幕上那坨报错的除错代码，恨不得把显示器砸了。误代项目明天就要交付，码文而那个该死的何删`utils.py`文件里多了一段我完全想不起来什么时候写进去的冗余逻辑。删除它？除错不行，怕删错。误代不删？码文编译都过不去。

后来我冷静下来，何删发现处理这种“错误代码文件”其实有套路，除错而且和大多数人想的误代不一样——第一步不是打开编辑器，而是码文先弄清楚你到底在删什么。

错误代码文件分两种。何删一种是除错整个文件都是垃圾，比如你从网上抄了个没用的误代脚本，或者同事离职前留下的半成品。另一种是文件本身有用，但里面混进了坏段落。后者更麻烦，因为直接删文件等于把婴儿和洗澡水一起泼掉。

对于第一种情况，我的做法很粗暴：先备份，再删除。备份不是让你复制粘贴到桌面，而是用`git rm`或者至少`mv file.py file.py.bak`。上周我删那个`old_parser.py`之前，就把它改名成`.bak`扔在项目目录里。三天后，测试发现新解析器有个边界条件没处理好，我还能翻出旧文件对照逻辑。

第二种情况，也就是文件里有坏代码，我见过太多人用注释把错误段落包起来——`# TODO: fix this`。这没用。注释掉的代码还在文件里，IDE的静态检查照样报错，而且阅读的人会困惑：这段到底还能不能用？正确做法是直接剪掉，别留尸首。

剪掉之前，先定位错误范围。别靠肉眼扫，用`git diff`看最近改动，或者用`python -m py_compile`跑一下，让解释器告诉你哪一行语法错了。如果错误是逻辑层面的（编译能过但运行结果不对），那就得靠调试器打断点，一步步走流程。上周我处理那个`data_cleaner.py`，就是靠`pdb`在可疑函数入口设断点，打印出中间变量，才确认是第47行的`strip()`误伤了合法空格。

定位到具体行之后，删除前先问自己一个问题：这段代码是否被其他模块引用？用`grep -rn "函数名"`搜一下项目里所有调用点。如果只有一处引用，直接删掉引用和定义。如果多处引用，那说明你面对的不是“错误文件”，而是“设计缺陷”——这时候删代码没用，得重构。

重构的删法又不一样。你得把坏逻辑抽出来，写个新函数替代，然后全局替换调用点。这活儿累，但值得。上周我花了两个小时把那个`legacy_convert()`函数从`utils.py`里拆出去，新建了`converter.py`，再把所有`from utils import legacy_convert`改成`from converter import new_convert`。跑完测试，全绿。

最后一步很多人会忘：删完之后，立刻跑一遍测试套件。别等到明天，别等“有空再说”。我见过太多人在删完代码的当天晚上就出问题——因为某个隐藏的依赖关系没被发现。跑测试不花几分钟，但能救你第二天的命。

顺便说一句，删完代码记得提交。提交信息写清楚：“移除过时的数据清洗逻辑，替换为基于pandas的实现”。别写“删点东西”，那样三个月后你自己都看不懂。

说到底，删除错误代码文件这事儿，本质是技术债的清偿。越早还，利息越低。拖到交付前夜再处理，你就得像我上周五那样，对着屏幕骂娘。