谷歌最佳实践 - 代码审核的速度

来源

代码审核的速度

为什么代码审核要快？

在谷歌，我们致力于优化开发团队交付产品的速度，同时也关注独立开发者编码速度的提升。尽管独立开发者的速度至关重要，但与整个团队相比仍存在一定差距。如果代码审核过慢，将会带来以下影响：

• 整组的效率会降低。当审核不能快速反馈时，单个开发可以投入其他的工作。然而对于小组来讲，新功能或者bug修复可能就会因为代码审核被延迟数天、数周甚至数月。
• 开发者会反对代码审核流程。如果审核者每次都需要数日才能有反馈，但是要求主要变更每次都要审核，开发者会感到沮丧和麻烦。大家会认为审核过程太过“严厉”。如果审核者要求同样可靠的变更（变更真实的提高了代码质量），但是在每次开发者提交更新时都能够快速响应，这样的抱怨就会消失。大部分关于代码审核流程的抱怨都能够在加快审核速度之后切实消除掉。
• 代码质量会受到冲击。当审核很慢时，会对开发者产生持续增加的压力，使得他们没办法以最好的状态提交代码。缓慢的审核也会影响代码整理、重构和基于现有代码的改进的意愿热情。

代码审核应该要多块？

如果你当前没有在一项专注的任务中，请务必在代码提交后尽快进行审核。
对于一次代码审核请求，请确保最晚反馈时间不超过一个工作日（例如第二天早晨的第一件事）。
遵守这些指南意味着典型的变更提交应在一天内进行多轮审核（如有必要）。

速度与打断

有时候个人效率是要高于团队效率的。例如，你正在全身心投入一项需要专注的工作中——比如写代码，这时候不要打断自己来进行代码审核。研究表明，一旦专注平滑的节奏被打断，开发者需要花很长时间才能重回这个状态。所以打断你个人的编码节奏对团队来讲，与让另外一位开发者等待代码审核实际上更昂贵。
你应当选择一个空档时间来进行代码审核的工作，比如当前的编码任务完成，午饭之后，会议结束后，或者一次茶歇之后等等。

快速响应

当我们讨论代码审核速度时，我们关注的是响应时间，即变更提交整体审核和提交所需的时间。理论上，整个过程应该快速进行，但是快速独立的反馈比整体过程的速度更重要。 即使有时候我们需要花费很长时间来完成整个审核过程，在这个过程中能够从审核者那里迅速获得反馈可以明显降低开发者对于“审核慢”的印象。 如果在有提交时你没有足够的时间来完成完整的审核工作，你可以先回复一下预计何时进行审核，并确认其他审核者是否有时间来做出响应。或者先提供一些初始宽泛通用的建议。（注意：这并不意味着你需要中断编码工作来提供反馈，而是在空闲时间内进行回应） 审阅人员需要投入足够多的时间在审查工作上以确保他们接受提交意味着“这份代码符合我们标准”。然而，请尽量确保单个响应速度较快。

跨时区审核

在面对时区差异的情况下，建议您尽量在对方仍在办公时间内回复。如果他们已经下班，我们应尽力确保审核工作能够在他们第二天上班前完成。

使用评论标志完成审核（LGTM1）

为了加快审核速度，我们将确定一些场景，即使在变更提交中备注他们尚未完成，也应通过审核。以下是这些情况：

• 审核者确信开发者能够很好的处理标记出来的所有问题。
• 待处理的内容很小而且不是必须由当前开发者完成。
  审核者需要明确当前是哪种情况，如果不是那就说明已经处理完毕了。
  评论中说明审核完成特别值得审核者与开发者在不同时区的组织考虑，否则开发者可能要等一整天，然后只为了等到一个通过评审的评论。

大型变更提交

如果某人提交的更改过于庞大，以至于您没有足够的时间来进行全面审核，您应该要求开发者将其拆分成几个较小的提交，而不是一次性审核一个巨大的变更。这对于审核者来说非常有帮助，尽管可能会增加开发者的工作量。 如果一个大型提交无法被拆分成较小的提交，并且您也没有足够时间来完整地审核整个变更，至少可以针对提交的总体设计提出一些评论，并向开发者提供反馈以便改进。作为审核者之一目标就是帮助开发者消除障碍或让他们能够放心地改进代码，而不必过度担心代码质量。

随着时间代码审核的改进

Code Review Improvements Over Time {#time}

如果您严格按照指南执行代码审核，您会发现随着时间的推移，审核速度也会越来越快。开发人员也能够理解如何提高代码质量，并且提交的变更也会比刚开始时更好，因此需要花在审核上的时间也越来越少。审核者还懂得快速响应，并且不需要在审核过程中增加无意义的延迟。 然而，请绝对不要因为考虑进度原因而在代码审核标准或质量上妥协。事实上，在长期任务执行中这样做并不能使事情进展更快。欲速则不达。

紧急情况

在某些紧急情况下，变更提交需要迅速通过完整的审核过程，此时可以适度放宽质量标准。接下来，我们需要根据《什么是紧急情况》一文来确定哪些情况被视为紧急，哪些不是。

接下来的文章：编写代码审核评论的技巧

1. Git 团队协作中常用术语的解释： - WIP：Work in progress，尚未完成，请勿合并。// 正在进行中 - LGTM：Looks good to me，我觉得不错。// 对他人的 Pull Request 进行审查时表示没有问题 - PTAL：Please take a look，请看一下。// 通常用于请求他人审查自己的 Pull Request - CC：Carbon copy，抄送。// 表示将信息抄送给其他人 - RFC：Request for comments，征求意见。// 我认为这个想法很好，请大家一起讨论下 - IIRC：If I recall correctly，如果我没记错的话。 - ACK: Acknowledgement, 确认接受或承认。 - NACK/NAK: Negative acknowledgement, 不同意。

posted on 2019-09-20 16:39  陈晨_软件五千言 阅读( ...) 评论( ...) 编辑 收藏

转载于:https://www.cnblogs.com/pluto4596/p/11558090.html

标签： 代码 开发者 在谷歌