紧急情况

紧急情况

有时候紧急 CL 必须尽快通过 code review 过程。

什么是紧急情况?

紧急 CL 是这样的更新:允许主要发布继续而不是回滚,修复显著影响用户生产的错误,处理紧迫的法律问题,关闭主要安全漏洞等。

在紧急情况下,我们确实关心 Code Review 的整体速度,而不仅仅是响应的速度。仅在这种情况下,审查人员应该更关心审查的速度和代码的正确性(是否解决了紧急情况?)。此外(显然)这类状况的审查应该优先于所有其他 code reivew。

但是,在紧急情况解决后,您应该再次查看紧急 CL 并进行更彻底的审查

什么不是紧急情况?

需要说明的是,以下情况并非紧急情况:

  • 想要在本周而不是下周推出(除非有一些实际硬性截止日期,例如合作伙伴协议)。
  • 开发人员已经在很长一段时间内完成了一项功能想要获得 CL。
  • 审查者都在另一个时区,目前是夜间或他们已离开现场。
  • 现在是星期五,在开发者在过周末之前获得这个 CL 会很棒。
  • 今天因为软(非硬)截止日期,经理表示必须完成此审核并签入 CL。
  • 回滚导致测试失败或构建破坏的 CL。

等等。

什么是 Hard Deadline?

硬性截止日期(Hard Deadline)是指如果你错过它会发生灾难性的事情。例如:

  • 对于合同义务,必须在特定日期之前提交 CL。
  • 如果在某个日期之前没有发布,您的产品将在市场上完全失败。
  • 一些硬件制造商每年只发送一次新硬件。如果您错过了向他们提交代码的截止日期,那么这可能是灾难性的,具体取决于您尝试发布的代码类型。

延迟发布一周并不是灾难性的。错过重要会议可能是灾难性的,但往往不是。

大多数截止日期都是软截止日期,而非最后期限。软截止日期表示希望在特定时间内完成某项功能。它们很重要,但你不应该以牺牲代码健康为前提来达到。

如果您的发布周期很长(几周),那么在下一个周期之前就可能会牺牲代码审查质量来获取功能。然而,如果重复这种模式,往往会给项目建立压倒性技术债务。如果开发人员在周期结束时经常提交 CL,只需要进行表面评审就必须“进入”,那么团队应该修改其流程,以便在周期的早期发生大的功能变更,并有足够的时间进行良好的审查。