最近我在捣鼓一个老项目，这系统用了快十年了，莫名其妙就报错。开发团队换了一批又一批，文档还乱七八糟。那天下午，刚吃完午饭，测试给我甩了个截图：“又挂了，赶紧看看”。我心想这都啥情况，得找出这个考古bug才行。
从头开始折腾
我先把代码库拉下来，git clone就搞了一刻钟，网络还卡得要死。接着开电脑终端， cd命令冲进去， ls查看文件，一堆垃圾文件夹，眼睛都花了。我决定从头翻历史提交， git log命令跑起来，几百条记录往下滚。看了半天，发现一个可疑的旧版本，好像是3年前一个叫“老李”的哥们改的。他那会儿加了个模块，但日志没写清楚，就一句话：“优化性能”。
动手模拟环境，我找个旧笔记本，下个老版Linux虚拟机安装起来，然后 git checkout那个版本。运行服务， sudo启动命令一输，果然崩了。弹出个错误窗口：“内存溢出”。我想，咋整？重启机器、清缓存、换参数，折腾到深夜。老婆喊我吃饭，我都顾不上。
用三个技巧快速挖缺陷
搞不定时，我抓了包烟坐阳台，回想老经验。琢磨出三个土法子，边做边学。
技巧一：挖祖坟看日志
- 打开日志文件，从第一行读起，一行行扫过去。
- 找到错误爆发点，往前翻几十页。
- 结合代码提交，发现有个老函数被多次改动，参数写错了。
那晚，我熬通宵，真挖出一个坑：老李改代码时，没检查数组长度，越界访问内存了。难怪在旧系统上疯狂崩。
技巧二：扮古人跑旧环境
- 在虚拟机里装老版本的操作系统和软件。
- 重跑那个bug触发场景，加点打印语句打印输出。
- 观察运行轨迹，卡住时断点调试，进函数看内部值。
我花一上午做这事，结果虚拟机卡死三回。但这回值了：看到内存分配错误，证实了祖坟日志的分析。心想，老系统就得靠这土法子，工具太新反而不灵。
技巧三：问老炮儿蹭经验
- 微信上找一个退休老同事，请喝茶聊聊天。
- 问他当年代码架构，有啥坑没填。
- 听他吐槽旧事，顺藤摸瓜挖线索。
聊到一半，老哥说：“当年这模块测试不到位，我们都忙项目急上线。”这tip一送，我回去查测试报告，果然发现漏测情况。三个技巧轮番上阵，问题根源挖出来了。
实现后的收尾
一步，我改了几行代码，把数组长度检查加上。然后上传提交，部署到测试环境，跑一遍压力测试，不报错了。老板发微信说：“干得”整个过程不复杂，就是耗时间，但土法子真管用。现在我也养成习惯了：每个老bug，都先挖祖坟、扮古人、问老炮儿。搞技术，磨叽下就能省事。
