如何用代码评审激励新工程师
如何用代码评审激励新工程师
原文：https://medium.com/hackernoon/maximizing-mentorship-in-code-review-f479ae74fe3f
最大化指导、提高代码质量和节省时间
Code review can be one of the most effective and collaborative avenues for mentorship. Photo by Helloquence.
许多人认为代码审查是一种防止 bug 影响生产的工具，或者是确保代码满足某个质量标准的工具。虽然经常是这些事情，但它也是一个不可思议的指导工具。既然已经有第二个人在阅读代码了，为什么不用一种可以教导和启发的方式呢？
在 Asana 工作期间，我有幸加入了几个不同的团队，并与一群新工程师(一些新毕业生和一些经验丰富的工程师)一起工作，亲眼目睹了代码审查对导师的好处。但是我也看到过代码审查出错的情况——例如，一个存在大问题的 diff，但是审查者只是用一个简单的“LGTM”或许多表面的 nits 来回应。尽管好的代码审查确实需要一些时间，但我已经找到了一些最好地利用这些时间的技巧和诀窍，目标是指导新的工程师，保持团队的高速度，并维护高质量的代码。
代码审查并不是万能的工具
虽然代码审查很棒，但它肯定不适合所有类型的反馈。当代码到达评审阶段时，它已经被写好了:一个工程师已经想通了一个设计，实现了它，测试了它，并且润色了一切。想象一下，经历了这些步骤，然后听到你的评审员说“这是一个糟糕的方法，你可以通过做 y 来避免 X。”这是非常消极的，需要大量的修改和更多的后续评审。相反，您应该在实施之前讨论变更——无论是通过设计文档还是简单的对话——以获得对整体方法的认可。
对于涉及大的设计变更的任务，在开始编码之前，写下你计划实现的内容的简短大纲(哪些文件、抽象的任何变更、各部分如何组合在一起)并与队友分享。这将揭示出学习的许多伟大的金块:组织你的思维和工程设计的方法，实施风险和替代方法，以及将你的改变分成更小块的方法。我发现这导致了代码质量的显著提高，并且节省的净时间令人难以置信。
编写代码时的提示
当您提交代码时，从代码审查者的角度考虑您将要提交的代码。我们所有人都应该希望评审者过得轻松——这不仅会节省他们的时间，还会提高你收到的反馈的质量。考虑以下提示:
在提交消息中给出详细的描述和测试计划
这听起来很傻，但是提交消息是有原因的！对于 UI 更改，包含一个截图或动画 GIF 来显示交互是非常有用的。这将使你的审阅者以正确的心态阅读你的修改，这将节省他们切换上下文的时间，并帮助他们集中注意力。
指出你意识到的任何问题
当发送代码评审时，我最喜欢做的事情之一是提及我可以预见的问题、我的变更中的怪癖或者我做出某些决定的原因。这确实很有帮助，原因如下:
- 为您的评审者突出显示这些方面，以便他们可以提供是否同意的意见，或者提供减轻风险的提示
- 节省您的评审人员处理复杂代码的时间，因为他们可以理解为什么会有复杂性
- 查看代码的未来工程师可以找到审查任务，并且可以洞察您的思维过程和决策
将你的承诺分成容易理解的部分
这是一个巨大的时间节省，我相信也导致更好的代码。将提交分成小块有助于您认识到糟糕的测试覆盖率、糟糕的文档或其他常见问题。此外，它通过减少每次提交的表面积来帮助您的评审者，从而节省他们理解变更的上下文的时间，并导致更好的反馈。
注意:Git 提供了一些工具来帮助你做到这一点，比如 git add -i 。
发现你不断收到类似的反馈？
通常，当您刚接触一个组织或代码库时，不可避免地会遇到许多小问题，而您仍在适应这个环境。对于我团队中的新工程师，我发现在我们的 1:1 项目中创建一个名为“公共代码评审反馈”的任务很有帮助。每当我们中的一个人在代码审查中注意到一个新的公共主题，我们就把它添加到这个任务中。这有两个目的:提供一个讨论这些项目的途径(例如，为什么这很重要？在代码审查之前，我如何识别这一点？)，以及跟踪提高代码质量的进展。我见过几次这种情况，它被用作一种惊人的激励和积极的强化——对于提交者和评审者来说，都能看到他们的反馈被听到。
审查代码时的提示
高效复习的策略
有时很难在快速的“LGTM”、只发现代码中的表面问题和花费数小时审查变更之间取得平衡。这并不容易，尤其是当更改不在您非常熟悉的代码区域时。在这些情况下，我试图将代码审查过程分成几个部分:
- 从高层次了解变化 首先，阅读提交消息。如果这是一个用户界面的变化，看看截图或 GIF 的变化。
- 了解表面区域的变化 读取被更改的文件列表。你最近看过这些文件吗？如果没有，先浏览一下(API 和文档)以了解它们。如果有太多的上下文需要获取，考虑抄送给其他人。通过获得更多关于已更改文件的上下文，你可以限制添加评论的次数，然后继续阅读，发现它们都是无意义的。
- 浏览更改，看看是否有任何 API、抽象或结构更改 不要看实际的实现更改。要看的最重要的事情之一是变化如何适应整个系统。是否有与这些变化不相容的后续变化(由其他人)即将到来？这些变化会导致其他人想要效仿的棘手或复杂的模式吗？ 你可能会决定重新考虑整个方法。在这些情况下，在解释你的想法时要机智(我经常选择问引导性的问题或联系其他例子)。此外，考虑到您可能遗漏了上下文，并且可能是错误的——工程师可能有很好的理由去做他们选择的事情。
- 最后，看看实际的实现变化和测试 现在，一旦你对高层次的变化感到满意，浏览代码并寻找表面层次的反馈。比如他们的方法是否简单易懂？他们是否遵循最佳实践和风格指南？他们是否给出了充分的意见？他们的变更有足够的测试覆盖率吗，或者有很好的理由错过测试吗？
一直给同样的反馈？
这可能会令人沮丧，尤其是对多人来说。考虑编写最佳实践的规范示例或文档，并在将来的代码评审中链接到它。这不仅可以节省你打字的时间，还意味着其他人可以阅读这份参考资料，对其进行扩展，或者问你关于潜在动机或哲学的问题。
我最喜欢的方法之一是作为“示例组件”和“示例测试”的一部分:真实的代码像所有其他代码一样存在，但只有一个目的，即教育最佳实践和潜在动机。
花很多时间在代码评审上？
是和特定的人吗？考虑花一些时间反思过去的几个代码评审。你注意到什么主题了吗？他们没有改进可能有潜在的原因，比如公司的工程价值观不清晰，或者某些工程理念不一致。我经常发现发送关于工程领域的文章或视频，并与工程师面对面交谈会很有帮助。
您是否经常收到难以审阅的代码？告诉工程师！没有人故意给评论者制造麻烦。向他们解释为什么代码难以审阅(例如，提交太大，提交消息令人困惑，或者代码太复杂)。亲自与他们一起审阅代码可能也会有所帮助，这将帮助他们了解为什么很难进行审阅。此外，不要害怕拒绝更改并要求他们解决提交结构或消息的问题；改进这一点的唯一办法是使问题浮出水面。
给出太多微不足道的评论？
有时，特别是对于新的工程师来说，有许多小而重要的事情要提。由编译器或 linter 来处理这些是理想的，但有时这是不可能的。留意你的反馈——最好一次只提到一小部分，或者亲自解释风格指南的高级理念。否则，作为审阅者，您可能会对自己的决策感到疲劳，而工程师可能会在看到永无止境的评论流时感到不知所措。你可以一直继续教工程师，如果你循序渐进地向他们介绍新概念和新知识，他们就会吸收更多的信息。
被收件箱里的评论压垮了？
每隔一段时间，我就会收到一份代码审查报告，其中有些内容我并不怎么感兴趣。不管是几个月没用过的旧代码，还是出了名的复杂的代码库。这完全正常，但这对任何人都没有好处，所以对此要认真反思，要真实。最好将评估报告交给其他人，这样做对评估来说更合适，或者，如果对时间不敏感，可以让它暂停几天。
【感谢】Greg Slovacek 的支持和贡献，感谢 R.J. Aquino、Tim Bavaro、Kevin Der、Bella Kazwell、Vincent Siao 和 Isaac Wolkerstorfer 审阅草稿。