上周帮朋友改一个五年前的 Python 脚本，打开文件第一眼看到 def get_data_from_xls_v2_fix2021_final_v3_backup.py 这个文件名，我就笑了——这哪是代码，这是考古现场。
维护不是重写，是读懂“前任”的脑回路
很多人一听说要维护旧项目，第一反应是：“重写吧，太乱了。”但现实往往是：老板说“下周上线新功能”，没给你三周重构时间。这时候，源码维护经验就不是加分项，是保命技能。
我习惯先花15分钟做三件事：
① 看 git log 最近三次提交，谁改的、为什么改、有没有带测试用例；
② 找出入口函数（比如 main() 或 app.run()），顺藤摸瓜画两行调用链；
③ 在关键函数里加一句 print(f'[DEBUG] {func_name} called with {args}') ，跑一遍流程，比读文档快十倍。
别信注释，信日志和 git blame
有次遇到一个定时任务总在凌晨3:17失败。注释写着“修复时区问题”，但实际是服务器 cron 用的是 UTC，而代码里硬写了 datetime.now().hour == 3。翻 git blame 发现，三年前某位同事深夜提交，commit message 写着：“临时绕过，等张工回来再改”。张工早离职了。
后来我在关键判断前补了一行：
logging.info(f'Current time: {datetime.now().isoformat()}, UTC now: {datetime.utcnow().isoformat()}')第二天一看日志，真相大白。
小改动，大留痕
改一行 if 判断？别急着保存。先在上面加个 TODO 注释，说明为什么不能用 else 分支，顺便提一句“此处逻辑依赖订单状态机 v1.2，勿合并到 dev 分支”。
这不是矫情，是给三个月后的自己留条活路。上次我删掉一个看似无用的 try-except 块，结果支付回调突然全量超时——原来那个 except 里悄悄重试了三次，还带退避延迟。
一个真实的小技巧
接手 Java 项目时，如果 config.properties 里一堆 key 没注释，别猜。直接在 IDE 里全局搜 getProperty("xxx")，看哪个类真正在用它。用不到的配置，哪怕看起来很“核心”，也先标灰、不删，加个 # [UNUSED AS OF 2024-06] 注释。
源码维护不是炫技，是让代码活得比你久一点，还别拖累你下班。