有时, 会出现紧急的代码修改, 对于这些修改需要尽可能快速的通过整个代码评审流程
紧急情况下的修改应该是小范围代码的改动,例如:能够使得重要提交被继续进行而非回滚, 修复显著影响用户体验的bug, 处理紧急的法律问题, 修复可能产生重大影响的安全漏洞等.
在紧急情况下, 我们十分关心整个代码的审查速度, 不单单是响应速度, 仅在这种情况下, 评审者应该更加注重评审速度和 代码的正确性(能否解决当前的紧急情况), 显然,当有紧急评审情况出现时, 对该情况的评审应处于最高优先状态.
并且, 在修复紧急情况之后, 应该再次查看CLs进行更加彻底的代码检查.
以下这些例子均不属于紧急情况:
- 期望在本周发布新的版本更新, 而不是在下一周 (除非一些特定原因导致必须在某个截止日期之前发布, 例如同合作伙伴之间有相关协定)
- 开发人员花费了很长的时间开发某个功能, 希望自己的修改得到通过
- 审阅人员处在另一个时区的深夜时间或者他们均远在异地
- 处在周末休息前的最后一天(如星期五), 期望能够在开发人员休息之前通过代码审阅
- 一位管理人员说审阅必须完成或者因为软性截至日期的原因导致CL审阅安排在今天
- 因为测试或者构建失败导致回滚的CL 等等
硬截止期限指的是:如果你错过这个时间会导致一些灾难性质的的事情发生, 例如:
- 合同规定必须在特定时间之前提交CL
- 你的产品没有在特定时间之前发布将会导致在市场上的完全失败
- 一些硬件制造商一年只发布一次新的硬件, 如果你没有在截止时间之前提交你的代码, 将会是灾难的, 具体取决于您将发布的代码类型.
将发布推迟一个星期并不会产生灾难性的后果. 错过一个重要的会议有可能会导致灾难性的后果,不过多数都不会
大部分的截止时间都是软截止期限(soft deadlines) 非硬截止时间(hard deadlines). 表示期望在某个时间之前完成某项功能的开发. 这个时间是重要的, 但是不能为了在这个时间之前开发完成而牺牲了代码的健壮性.
如果发布的周期较长(几周), 为了在下一个发布周期之前发布新的功能，你可能会忍不住牺牲代码审阅的质量. 然而, 如果重复这种模式. 容易导致积累过多的"技术债". 如果开发人员习惯性地在发布周期快结束之前提交CL，并让审核草草了事, 那就说明团队亟需修改工作流程, 以保证大的功能改动在整个发布周期中尽早完成,进而确保这些改动能有充足的时间来进行审阅.