去年我接了一个内部系统：上线五年，作者三年前离职，说明文档还是脚手架里带的那份。代码能跑，接口每天有几千次调用，谁也不敢大改。
接下来那个月我做的事情，现在回看可以归结成三个地方。
一、表结构，以及所有改过它的脚本
代码可以重构，数据不能重来。所以我第一天先把表结构和索引导出来，一张一张看。
看的时候我不太关心字段命名，只关心三件事：哪些字段事实上是枚举却没有约束、哪些时间字段存的是本地时间、哪些表在持续变大。
那次就撞上一个典型问题：两张表里的「创建时间」用的不是同一个时区。一张写 UTC，另一张写本地时间，而报表把两张表按月关联统计，每个月头一天的数据都会少。这个问题在业务上吵了两年，谁都以为是报表工具的毛病。
统一到 UTC 的迁移脚本我写了半天，找它花了三天。
二、日志、错误上报和配置
老项目最麻烦的不是代码看不懂，而是出问题的时候你什么都看不见。
我会挨个确认三件事：日志输出到哪里、保留多久；有没有错误上报；配置是从环境变量读的，还是写死在某个文件里。
最想提醒的是配置。很多老项目里会有一份「本地能用」的配置文件被一起带上了服务器，里面混着测试环境的地址。这个坑我自己踩过一次：改完配置重启，接口连到了测试库，当天下午写进去的数据全放错了地方。
所以接手之后我做的第一件「有副作用」的改动，通常是给启动日志加一行 —— 打印当前生效的数据库地址和版本号。看上去没什么技术含量，但它能在出事的第一分钟救你一次。
再就是备份。老项目的数据库往往没人认真备份过，我会在动任何数据之前先手工导一份出来，哪怕它只是躺在硬盘上。
三、最近半年的提交记录
第三个地方是版本库。我一般看两样东西：最近半年谁在提交、都在改哪些文件；以及散落在代码里的 TODO 和 FIXME。
提交记录能告诉你这个项目真实的维护状态。如果最近半年只有一两次提交，说明它已经进入「能不动就不动」的阶段，那我的策略会偏保守：先补测试和监控，不碰核心逻辑。反过来，如果它每周都有人在改，那要小心的是历史包袱 —— 因为那些改动大概率没经过完整的回归。
TODO 注释是另一种情报。它们往往标着当年就知道有问题、但因为排期没处理的地方，通常也是后来最容易出故障的位置。我接手时列了十七条，最后确认有九条是真问题。
收尾
接手老项目最大的心态问题，是想先「把它理顺」。
但五年积累的问题不是一个月能理顺的。你能做的是先给自己搭一张地图：数据在哪里、出问题怎么看见、改动会被谁碰到。
地图画完，后面每一次修改才有底气。
