紧急情况

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

紧急情况的定义

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

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

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

哪些不属于紧急情况?

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

• 期望在本周发布新的版本更新, 而不是在下一周 (除非一些特定原因导致必须在某个截止日期之前发布, 例如同合作伙伴之间有相关协定)

• 开发人员花费了很长的时间开发某个功能, 希望自己的修改得到通过

• 审阅人员处在另一个时区的深夜时间或者他们均远在异地

• 处在周末休息前的最后一天(如星期五), 期望能够在开发人员休息之前通过代码审阅

• 一位管理人员说审阅必须完成或者因为软性截至日期的原因导致CL审阅安排在今天

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

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

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

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

• 你的产品没有在特定时间之前发布将会导致在市场上的完全失败

• 一些硬件制造商一年只发布一次新的硬件, 如果你没有在截止时间之前提交你的代码, 将会是灾难的, 具体取决于您将发布的代码类型.

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

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

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