接手一个没人维护的老项目，我第一周只做了三件事

上周被拉去接手一个内部系统，上一任开发三月份就走了。代码在，文档没有，提交记录里最后一次改动叫「修复」。

我一开始也想直接读代码。翻了两个小时 controller，越看越虚——不是看不懂，是不知道哪部分还活着。后来干脆停下来，先不读。

第一件事：把系统跑起来，然后点一遍

不是看代码结构，就是把每个菜单点进去，看哪个页面报错、哪个按钮转圈、哪个功能点进去是空白。半天时间列了十一条「看着能用其实不能用」的地方。这比读一周代码有用，因为用户真正抱怨的就是这些。

顺手把环境也记下来了。哪个配置文件里躺着明文密码，哪个依赖装的是内网源，启动脚本里写死了某个同事电脑上的路径。这些没人会告诉你，只能自己踩。

第二件事：翻日志

老系统最值钱的不是代码，是日志。我把最近一个月的错误日志按出现次数排了个序，前三条占了七成：数据库连接池不够、某个定时任务每天凌晨重跑失败、还有一条内存溢出的警告，出现时间很规律，基本都在下午两点左右。

下午两点这个时间点帮了大忙。后来查出来是有人配了个整点同步，量一上来就 OOM。这问题大概存在半年了，一直没人管，因为重启一下就好了。

第三件事：给最脏的那个方法加日志，不加注释

本来想写注释，写着写着发现没用——我不知道它为什么这么写，猜出来的注释比没有注释更害人。所以改成在入口和出口各打一行日志，把入参和耗时记下来。跑了一周，这个方法被调了多少次、慢在哪一段，全清楚了。

有人问为什么不先重构。因为我不确定哪块能删。删错了线上就炸，而我对这个系统的了解还不足以承担这个风险。

三周过去，十一条里修了七条，剩下的排进下个迭代。代码结构基本没动，但至少现在我知道它哪里疼。

回头看，第一周做的三件事其实都不算技术活：点一遍、翻日志、加两行打印。但它们让我少走了很多弯路。

如果非要说有什么经验，就是别急着证明自己能看懂代码，先证明自己能看懂这个系统在干什么。