有时候紧急 CL 必须尽快通过 code review 过程。
什么是紧急情况？
紧急 CL 是这样的小更新：允许主要发布继续而不是回滚，修复显著影响用户生产的错误，处理紧迫的法律问题，关闭主要安全漏洞等。
在紧急情况下，我们确实关心 Code Review 的整体速度，而不仅仅是响应的速度。仅在这种情况下，审查人员应该更关心审查的速度和代码的正确性（是否解决了紧急情况？）。此外（显然）这类状况的审查应该优先于所有其他 code reivew。
但是，在紧急情况解决后，您应该再次查看紧急 CL 并进行更彻底的审查。
什么不是紧急情况？
需要说明的是，以下情况并非紧急情况：
- 想要在本周而不是下周推出（除非有一些实际硬性截止日期，例如合作伙伴协议）。
- 开发人员已经在很长一段时间内完成了一项功能想要获得 CL。
- 审查者都在另一个时区，目前是夜间或他们已离开现场。
- 现在是星期五，在开发者在过周末之前获得这个 CL 会很棒。
- 今天因为软（非硬）截止日期，经理表示必须完成此审核并签入 CL。
- 回滚导致测试失败或构建破坏的 CL。
等等。
什么是 Hard Deadline？
硬性截止日期（Hard Deadline）是指如果你错过它会发生灾难性的事情。例如：
- 对于合同义务，必须在特定日期之前提交 CL。
- 如果在某个日期之前没有发布，您的产品将在市场上完全失败。
- 一些硬件制造商每年只发送一次新硬件。如果您错过了向他们提交代码的截止日期，那么这可能是灾难性的，具体取决于您尝试发布的代码类型。
延迟发布一周并不是灾难性的。错过重要会议可能是灾难性的，但往往不是。
大多数截止日期都是软截止日期，而非最后期限。软截止日期表示希望在特定时间内完成某项功能。它们很重要，但你不应该以牺牲代码健康为前提来达到。
如果您的发布周期很长（几周），那么在下一个周期之前就可能会牺牲代码审查质量来获取功能。然而，如果重复这种模式，往往会给项目建立压倒性技术债务。如果开发人员在周期结束时经常提交 CL，只需要进行表面评审就必须“进入”，那么团队应该修改其流程，以便在周期的早期发生大的功能变更，并有足够的时间进行良好的审查。