这位 senior 用 1 个动作教会我：代码写得好不如崩溃时坐得住

入职半年，我提交代码的速度全组最快，加班时长全组最长。直到生产环境崩掉那天，我才发现自己完全不知道怎么开始排查。

Slack 消息以每秒十几条的速度往上刷，我的心跳比通知还快。而 senior 开发 Youssef 只是拉了下椅子，戴上耳机，像处理日常需求一样开始逐行看日志。

「快」是一种幻觉

新人时期的我把「关闭工单速度」当成核心指标。早走的人被我默认划进「不够拼」的阵营，晚走的自己则有种隐秘的优越感。

Youssef 从不加班。每天六点准时消失，但第二天总能给出比熬夜方案更干净的实现。我当时把这归结为「他经验多」，没意识到这是两种完全不同的工作模式。

崩溃现场他花了 40 分钟定位问题，修复只改了 3 行。我在旁边看着，突然意识到自己过去半年写的「快速修复」里，有多少会在未来变成同样的生产事故。

senior 的「慢」藏在哪

后来我开始观察 Youssef 的日常节奏。他写代码前会花 15 分钟画流程图，不是给别人看，是给自己理清边界条件。代码审查时他逐行追问「如果这里返回空，下游怎么处理」，而我之前看到能跑就过。

最反差的是他处理阻塞的方式。遇到依赖方延迟，我会反复刷新 Slack 催进度，他直接写 mock 数据继续推进，同时给依赖方发一封不带情绪的时间线邮件。两件事并行，互不干扰。

这些习惯从不写在周报里，代码仓库也看不到痕迹。但它们决定了一个人能否在服务器崩溃时，把心率控制在正常范围。

我偷学的第一招

现在遇到线上故障，我会先强制自己离开键盘 30 秒。倒水、站起来、或者只是盯着屏幕但不碰鼠标。这个停顿足够让肾上腺素回落，避免「赶紧改点什么」的冲动型操作。

Youssef 后来告诉我，他早期也经历过 panic 阶段，直到发现 80% 的故障恶化都来自「第一反应式修复」。坐得住不是性格，是训练出来的肌肉记忆。

上周我独立处理了一次缓存穿透问题，从发现到解决用了 52 分钟。团队群里有人夸「处理得稳」，我只回复了一个 。没人知道我在那 52 分钟里，把 Youssef 拉椅子的动作在心里重复了多少遍。

你现在遇到线上故障的第一反应是什么？是打开日志，还是先刷新监控面板看有没有人发现？