接手陌生代码库的前 60 分钟：我固定做的 6 件事

接手一个陌生的代码库，最浪费时间的不是看不懂代码，而是不知道从哪里看起，于是一路从入口文件往下翻，翻了半小时还在路由层。

我现在有一套固定流程，60 分钟内能给出三样产出：这个项目怎么跑起来、数据从哪来到哪去、我下一步该改哪个文件。

第 1 件事：先读「非代码」的四类文件（10 分钟）

顺序很重要，从最省力的开始：

1. README：只看"怎么跑"和"有什么功能"两段，跳过宣传语
2. 依赖清单（package.json / requirements.txt / pom.xml）：技术栈与版本，顺带看有没有明显过时的核心依赖
3. 配置文件（.env.example、config.*）：这是最容易被低估的，它几乎等于项目的"可调参数清单"
4. CI 配置（.github/workflows、Jenkinsfile）：这里写着"作者认为什么才算正确"，测试命令、构建步骤、代码检查规则全在里面

读完这四类，你比读十个业务文件更了解这个项目。

第 2 件事：找到「唯一的入口」和「唯一的出口」（10 分钟）

任何项目都有这两端：

• 入口：HTTP 路由表、消息队列消费者、命令行入口、定时任务注册处
• 出口：数据库访问层、外部 API 客户端、文件写入点

我一般直接搜这些特征字符串：

# 入口
grep -rn "router\|@GetMapping\|@app.route\|addEventListener('message'" --include=*.{js,ts,py,java} | head -30
# 出口
grep -rn "fetch(\|axios\|requests.post\|INSERT INTO\|fs.writeFile" | head -30

得到两张清单后，项目的数据流就闭合了：请求从哪进来、落到哪张表、又被谁读出去。

这一步的产出比"读完所有文件"有用得多，因为后面任何细节都能挂到这两张图上。

第 3 件事：跑一次，但只跑最小路径（15 分钟）

不要一上来跑全量测试（可能半小时还没跑完）。先做三件事：

1. 依赖装好、服务起起来
2. 找一个只读接口（列表、详情）打通
3. 看一次成功日志长什么样

为什么要看成功日志？ 因为将来出问题时，你要靠"正常长什么样"来判断异常。很多人跳过这步，然后每次排查都在猜。

第 4 件事：git log 只看「第一次提交」和「最近十次」（10 分钟）

• 第一次提交：往往能看到项目最初的结构设计，比现在更干净，能帮你理解作者的本意
• 最近十次：能看出当前正在改什么、哪些文件最活跃

再补一个技巧：

git log --oneline --since="3 months" --name-only | \
  awk '{print $1}' | sort | uniq -c | sort -rn | head -20

这张"热点文件表"直接告诉你：近三个月的维护重心在哪。要改需求，先看这几个文件。

第 5 件事：找一处"最小的坏味道"，试着改掉（10 分钟）

这一步不是给别人看的，是给自己建立信心的。

挑一个明显的小问题：拼写错误、重复的判断、写死的常量、没有边界的除法。改掉、跑测试、提一个 commit（或者只写进笔记）。

为什么值得做？ 因为它验证了你对"改代码 → 验证"这条链路的掌握程度。如果改一行代码你都不知道怎么验证，那说明你还不能用这个项目干活，得回去补第 3 步。

第 6 件事：写下三行笔记（5 分钟）

最后，逼自己写三行：

怎么跑：<一条命令>
数据流：<入口> → <核心表/服务> → <出口>
下一步：<我接下来要动的文件 + 理由>

写不出来，说明前五步有一步没到位。

这三行以后会是你在群里回答"这个项目怎么跑"的唯一依据，也是你三天后回来继续干活的起点。

一个提醒：不要试图「全部读懂」

陌生代码库最容易陷入的陷阱是"我要先全部理解再动手"。

实际上没有人是全部读懂才开始改代码的，包括原作者。真实做法是：带着一个具体问题（“这个接口为什么返回空”）去读，读完这个问题相关的路径就够了。

理解是沿着需求长出来的，不是先铺满再使用。

小结

60 分钟的分配大概是：

这套流程的价值不在于快，而在于每一步都有明确产出。没有产出的"阅读"，本质上是在拖延。