谷歌最佳实践 - 代码审核的速度
代码审核的速度
为什么代码审核要快？
在谷歌，我们会对一个开发团队交付产品的速度进行优化，另外一面就是优化独立开发者的编码速度。独立开发者的速度很重要，但是绝对无法与整组的速度相比。
如果代码审核太慢，就会产生下面的影响：
- 整组的效率会降低。当审核不能快速反馈时，单个开发可以投入其他的工作。然而对于小组来讲，新功能或者bug修复可能就会因为代码审核被延迟数天、数周甚至数月。
- 开发者会反对代码审核流程。如果审核者每次都需要数日才能有反馈，但是要求主要变更每次都要审核，开发者会感到沮丧和麻烦。大家会认为审核过程太过“严厉”。如果审核者要求同样可靠的变更（变更真实的提高了代码质量），但是在每次开发者提交更新时都能够快速响应，这样的抱怨就会消失。大部分关于代码审核流程的抱怨都能够在加快审核速度之后切实消除掉。
- 代码质量会受到冲击。当审核很慢时，会对开发者产生持续增加的压力，使得他们没办法以最好的状态提交代码。缓慢的审核也会影响代码整理、重构和基于现有代码的改进的意愿热情。
代码审核应该要多块？
如果你当前没有在一项专注的任务中，你就应该在代码提交后尽快进行审核。
针对一次代码审核请求最晚反馈时间不要超过一个工作日。（例如第二天早晨的第一件事）
遵守这些指南的话，意味着一次典型的变更提交应当是会在一天内进行多轮审核（如果有必要）。
速度与打断
有时候个人效率是要高于团队效率的。例如，你正在全身心投入一项需要专注的工作中——比如写代码，这时候不要打断自己来进行代码审核。研究表明，一旦专注平滑的节奏被打断，开发者需要花很长时间才能重回这个状态。所以打断你个人的编码节奏对团队来讲，与让另外一位开发者等待代码审核实际上更昂贵。
你应当选择一个空档时间来进行代码审核的工作，比如当前的编码任务完成，午饭之后，会议结束后，或者一次茶歇之后等等。
快速响应
当我们在讨论代码审核的速度时，我们关心的就是响应时间，相对的就是变更提交整体审核并提交共花费多少时间。整个过程理论上应该要快速，但是快速的独立反馈比整体的过程速度更加重要。
哪怕有时我们需要花很长的时间来完成整个审核过程，在过程中能够从审核者很快的获得反馈，就能够明显的降低开发者对于“审核慢”的印象。
如果当有提交时你没有足够的时间来做完整的审核，你可以先回复一下你预计什么时候会进行审核，确认其他审核者是否能够有时间来响应，或者先提供一些初始的宽泛通用的建议。（注意：这并不意味着你需要中断你的编码工作来进行反馈，你仍然应该在空档时间进行回应。）
审核者需要在审核工作上投入足够多的时间来确保他们接受提交就意味者“这份代码符合我们的标准”。然而尽量保证单个响应速度要快。
跨时区审核
当存在时区差异的时候，尽量要在他还在办公室的工作时间内回复。如果他们已经下班来，尽量在他们第二天上班前完成审核。
使用评论标志完成审核（LGTM[1]）
为了提高审核的速度，会有一些确定的场景应该通过审核，即使他们在变更提交中备注他们还没有完成。下面就是这些情况：
- 审核者确信开发者能够很好的处理标记出来的所有问题。
- 待处理的内容很小而且不是必须由当前开发者完成。
审核者需要明确当前是哪种情况，如果不是那就说明已经处理完毕了。
评论中说明审核完成特别值得审核者与开发者在不同时区的组织考虑，否则开发者可能要等一整天，然后只为了等到一个通过评审的评论。
大型变更提交
如果某人提交过来的变更非常大，大到你没有足够的时间能够审核，你应当要求开发者将这个提交拆分成几个更小的提交，而不是一次性审核一个很大的提交。这个对于审核者是很有帮助的，虽然可能会增加一些开发者的工作量。
如果说一个大型提交没办法拆分成更小的提交，你也没有足够的时间来完整审核完整个提交，至少可以针对提交的整体设计提出一些评论并且反馈给开发者用于改进。作为审核者的目标之一就是帮助开发者清除障碍或者能够让他们放心的改进代码，而不用太过担心代码质量。
随着时间代码审核的改进
Code Review Improvements Over Time
如果跟随指南严格执行代码审核，你会发现随着时间变化审核的速度也会越来越快。开发者也能理解如何提高代码质量，变更提交也会比刚开始更好，需要花在审核上面的时间也越来越少。审核者也懂得快速响应，并且不需要在审核过程中加入无意义的延迟。
但是决不要因为考虑到进度原因，在代码审核标准或者质量上妥协 ，事实上在长期的任务执行中，也不会让事情进行的更快。欲速则不达。
紧急情况
某些紧急情况下，变更提交必须非常快通过完整审核过程，这时候质量标准可以适当放松。然后需要根据《什么是紧急情况》一文来判定什么情况是紧急什么不是。
下一篇：如何写代码审核评论
Git 团队协作中常用术语 WIP PTAL CC LGTM 等解释
WIP : Work in progress, do not merge yet. // 开发中
LGTM : Looks good to me. // Riview 完别人的 PR ，没有问题
PTAL : Please take a look. // 帮我看下，一般都是请别人 review 自己的 PR
CC : Carbon copy // 一般代表抄送别人的意思
RFC : request for comments. // 我觉得这个想法很好, 我们来一起讨论下
IIRC : if I recall correctly. // 如果我没记错
ACK : acknowledgement. // 我确认了或者我接受了,我承认了
NACK/NAK : negative acknowledgement. // 我不同意 ↩︎
