有時候有些緊急的 CL 需要盡可能快地通過整個程式碼審查流程。
Sometimes there are emergency CLs that must pass through the entire code review process as quickly as possible.
緊急 CL 將是一個「小」更改，允許主要的發佈繼續進行而不會復原，修復影響使用者產生重大影響的錯誤，在生產環境中處理迫切的法律問題，關閉主要的安全漏洞等。
An emergency CL would be a small change that: allows a major launch to continue instead of rolling back, fixes a bug significantly affecting users in production, handles a pressing legal issue, closes a major security hole, etc.
在緊急情況下，我們真的關心整個程式碼審查過程的速度，而不僅僅是回覆速度。在這種情況下，審查者應更關心審查的速度和程式碼的正確性（它是否真正解決了緊急情況？），而不是其他任何事情。此外（很明顯地），當這些問題出現時，此類檢討應優先於所有其他程式碼檢討。
In emergencies we really do care about the speed of the entire code review process, not just the speed of response. In this case only, the reviewer should care more about the speed of the review and the correctness of the code (does it actually resolve the emergency?) than anything else. Also (perhaps obviously) such reviews should take priority over all other code reviews, when they come up.
然而，在緊急情況得以解決後，您應該重新審視緊急變更清單，並進行更全面的審查。
However, after the emergency is resolved you should look over the emergency CLs again and give them a more thorough review.
為了明確起見，以下情況不是緊急情況：
To be clear, the following cases are not an emergency:
等等就是這樣。
And so on.
一個硬期限是指如果你錯過了它，會發生災難性的事情。例如：
A hard deadline is one where something disastrous would happen if you miss it. For example:
推遲一週的發行並不會導致災難。錯過重要的會議可能會是災難，但通常不會。
Delaying a release for a week is not disastrous. Missing an important conference might be disastrous, but often is not.
大多數的期限都是較為寬鬆的期限，而非嚴格的期限。它們代表了希望在某個特定時間內完成某項功能的願望。期限的確很重要，但您不應該為了達成它們而犧牲程式碼品質。
Most deadlines are soft deadlines, not hard deadlines. They represent a desire for a feature to be done by a certain time. They are important, but you shouldn’t be sacrificing code health to make them.
如果您的發佈週期很長（數週），為了在下一個週期之前將功能新增到程式碼中，可能會有一些妥協程式碼審查品質的誘惑。然而，如果重複此模式，專案積累的技術債務會變得很難處理。如果開發人員經常在週期接近結束時提交必須加入的 CL，卻只進行了表面上的審查，那麼團隊應修改其流程，使大型功能更改在週期初期完成，並有足夠的時間進行良好的審查。
If you have a long release cycle (several weeks) it can be tempting to sacrifice code review quality to get a feature in before the next cycle. However, this pattern, if repeated, is a common way for projects to build up overwhelming technical debt. If developers are routinely submitting CLs near the end of the cycle that “must get in” with only superficial review, then the team should modify its process so that large feature changes happen early in the cycle and have enough time for good review.