Add simplified Chinese translation (#1)

zh-cn/review/emergencies.md

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