有时, 会出现紧急的代码修改, 对于这些修改需要尽可能快速的通过整个代码评审流程

紧急情况的定义

紧急情况下的修改应该是小范围代码的改动，例如：能够使得重要提交被继续进行而非回滚，修复显著影响用户体验的bug，处理紧急的法律问题，修复可能产生重大影响的安全漏洞等。
在紧急情况下, 我们十分关心整个代码的审查速度, 不单单是响应速度, 在这种情况下, 评审者应该更加注重评审速度和代码的正确性(能否解决当前的紧急情况)，当有紧急评审情况出现时, 对该情况的评审应处于最高优先状态。并且, 在修复紧急情况之后, 应该再次查看CLS进行更加彻底的代码检查。

哪些不属于紧急情况

以下这些例子均不属于紧急情况：

  • 期望在本周发布新的版本更新, 而不是在下一周 (除非一些特定原因导致必须在某个截止日期之前发布, 例如同合作伙伴之间有相关协定)
  • 开发人员花费了很长的时间开发某个功能, 希望自己的修改得到通过
  • 审阅人员处在另一个时区的深夜时间或者他们均远在异地
  • 处在周末休息前的最后一天(如星期五), 期望能够在开发人员休息之前通过代码审阅
  • 一位管理人员说审阅必须完成或者因为软性截至日期的原因导致CL审阅安排在今天

  • 因为测试或者构建失败导致回滚的CL
    等等

    Hard Deadline(硬截止期限)的定义是什么

    硬截止期限指的是：如果你错过这个时间会导致一些灾难性质的的事情发生, 例如:

  • 合同规定必须在特定时间之前提交CL

  • 你的产品没有在特定时间之前发布将会导致在市场上的完全失败
  • 一些硬件制造商一年只发布一次新的硬件, 如果你没有在截止时间之前提交你的代码, 将会是灾难的, 具体取决于您将发布的代码类型.

大部分的截止时间都是软截止期限(soft deadlines) 非硬截止时间(hard deadlines). 表示期望在某个时间之前完成某项功能的开发。这个时间是重要的, 但是不能为了在这个时间之前开发完成而牺牲了代码的健壮性，如果发布的周期较长(可能几周)， 为了在下一个发布周期之前发布新的功能，你可能会忍不住牺牲代码审阅的质量。然而, 如果重复这种模式，容易导致积累过多的”技术债”。 如果开发人员习惯性地在发布周期快结束之前提交CL，并让审核草草了事，那就说明团队亟需修改工作流程, 以保证大的功能改动在整个发布周期中尽早完成，进而确保这些改动能有充足的时间来进行审阅。