3天代码审查问题（以及它实际上给你带来的成本）

Source: Dev.to

一位开发者最近在 Reddit 上发了这段话：

“人们通常要花大约一周的时间来审查我的改动……在我看来，等半个冲刺才得到反馈简直疯狂。”

他们的团队采用两周冲刺，而审查却需要一周时间。他们提出 “当天或次日” 完成审查的要求，却得到 “几个人投来奇怪的眼神，好像我在说疯话或不讲理。” 当他们询问同事审查 应该 多久完成时，大多数人回答 “3‑4 天”。 随后产生的讨论串有超过 50 条回复。

让我印象深刻的不是建议本身，而是各团队之间对“正常”审查时长的认知差异之大。

可行性与接受度之间的差距

将审查视为优先的团队

“我的团队在同一天或次日完成审查，并尽可能偏好小而集中的变更集。”
“作为技术负责人，我的目标是在收到审查后的一小时内完成审查。这已写入我的工作描述，并且影响团队的速度。”
“我的 Jira 指标显示，对所有客户公司（从打开到合并）不超过 20 小时，这包括处理评论、变更请求以及潜在的返工。”

规范较慢的团队

“我以前的团队会在同一天完成。后来我加入的团队需要一周时间。现在我所在的团队，2‑3 天是常态。”
“我开始当前合同工作时，审查需要 1‑3 周。”

同一行业。同类工作。完全不同的期望。

等待的真实代价

一个回复概括了：

“任何等待都是不好的，并且以各种方式花钱——上下文切换、合并冲突、在写完代码后 15 分钟内发现错误，而不是一周后才发现。”

原帖作者描述了实际影响：

“我比其他队友更快，所以我在这个团队的 MR 像火车车厢一样堆积……我实际上会避免接手新任务，以免上下文过载，因为我需要完成待处理的工作。”

再读一遍。 开发者正在有意放慢速度，因为审查流程跟不上。他们在管理自己的吞吐量，以弥补系统的缺陷。

另一条回复将问题与更广泛的研究联系起来：

“这对许多组织来说是一个重大问题，解决它是值得的（参见 Accelerate by Dr. Forsgren）。”

Accelerate 研究 () 显示，精英团队的交付周期——从提交到生产——以小时计，而不是周。如果仅审查就需要 3‑4 天，你已经远远超出高绩效团队端到端的完成速度。

高绩效团队的实际做法

将审查视为阻塞，而非待办事项

“PR 应视为阻塞并尽快处理。”
“在我参与过的最佳团队中，准则是一天开始时先审查所有待处理的 MR，然后再编写其他代码。”

设定明确的时间约定

“我们对大多数代码审查的期望是 24 小时内完成。”
“我期望必需审查者在每个迭代中 24 小时内回复……24 小时后就会开始发送提醒。”
“最多四小时。之后我会私信相关人员进行审查。”

保持改动小且易于审查

“我学会了压缩提交大小。现在我的提交是……我们在一天内审查所有改动。我们保持工单和改动小巧，以便易于阅读和理解。”

将审查视为工作的一部分，而非打断

“我们对所有合并请求进行当天审查，目标是在提交后一小时内完成。我们所有人的代码都会被合并，这实际上就像我们需要别人完成审查的程度与我们需要完成审查的程度相同，最终会相互抵消。”

Why nothing changes

The most honest observation in the thread:

“The situation is surreal, but it’s also disturbingly normal and organizations tend to be very slow to move off their broken process no matter how large the evidence that it works badly.”

团队都知道冗长的评审会带来伤害。很多人读过 Accelerate，并且体会到切换回一周前的代码时的痛苦。然而，这一流程仍然存在，原因如下：

• No visibility – 你看不见的东西就无法改进。没有数据时，“评审很慢”只是一种感觉，容易被忽视。
• No baseline – 你的团队正常的节奏是什么？本次冲刺比上一次更糟吗？没有跟踪就无法得知。
• No accountability – 24 小时的约定如果没人能判断何时被违反，就毫无意义。

原帖作者完美地捕捉到了这种功能失调：

“Teams putting processes before people and then claiming to do agile.”

调试你的流程，而不是你的团队

你的评审所需的时间恰好等于你所设计的系统所允许的时间。
评审之所以慢并不是因为开发者懒惰。工作流是你设计的，重新设计也是你的职责。就像任何调试一样，它始于可视化。

当部署失败时，你不会猜测原因——而是查看日志、追踪错误、找到出错的代码行。你的评审流程也应该得到同样的对待：

• 项目实际在评审中停留多长时间？
• 哪些转换比较慢？
  • 开发完成 → 正在评审？
  • 正在评审 → 评审完成？
  • 评审完成 → 正在测试？
• 24 小时的约定是否得到遵守？

这些问题都很容易回答——前提是你收集了数据。

我是 Time In Status 的首席开发者。

[3‑day code review problem](?utm_source=...&utm_medium=...&utm_campaign=...&utm_content=3day-code-review-problem) by Smart Guess — it shows you how long Jira issues spend in each status, so you can see where work waits, spot review bottlenecks before they pile up, and finally have data for those “why did this take so long?” conversations.