View on GitHub

eng-practices-cn

谷歌工程实践

紧急情况

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

紧急情况的定义

紧急情况下的修改应该是小范围代码的改动,例如:能够使得重要提交被继续进行而非回滚, 修复显著影响用户体验的bug, 处理紧急的法律问题, 修复可能产生重大影响的安全漏洞等.

在紧急情况下, 我们十分关心整个代码的审查速度, 不单单是响应速度, 仅在这种情况下, 评审者应该更加注重评审速度和 代码的正确性(能否解决当前的紧急情况), 显然,当有紧急评审情况出现时, 对该情况的评审应处于最高优先状态.

并且, 在修复紧急情况之后, 应该再次查看CLs进行更加彻底的代码检查.

哪些不属于紧急情况?

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

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

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

将发布推迟一个星期并不会产生灾难性的后果. 错过一个重要的会议有可能会导致灾难性的后果,不过多数都不会

大部分的截止时间都是软截止期限(soft deadlines) 非硬截止时间(hard deadlines). 表示期望在某个时间之前完成某项功能的开发. 这个时间是重要的, 但是不能为了在这个时间之前开发完成而牺牲了代码的健壮性.

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