当您收到同事的代码审查请求时，您会关注什么？对于您认为值得评论的事情，什么达到了标准？当您对某事发表评论时，您是否清楚地表明了某事对更改的重要性，以至于代码审查不应该在没有它的情况下合并？
代码审查很难。我见过人们做得很好，也有人做得很差，但我们大多数人都处于中间位置。向人们提供反馈是很困难的，而且需要练习才能对你过去几天思考的那段大段代码感到自在地接受反馈。代码审查对团队的节奏非常重要，但对他们的幸福也很重要。我已经看到糟糕的代码审查几乎声名狼藉，并损害了团队的文化，因为人们开始觉得分享他们的代码以供审查是不安全的。良好的代码审查流程可以让您在代码库中获得更好的代码，同时为您的团队带来好运、增加知识共享并为团队成员提供相互学习的绝佳机会。
考虑到这一点，以下是我学到的一些东西，它们帮助我改进了代码审查——我从别人那里得到的评论，以及我给别人的评论：
- 尽可能多地自动化代码审查。代码审查不是为了对语法进行评论，或者在双引号上使用单引号，或者发现未使用的变量。严格使用 ESLint 或其他此类工具来强制执行团队的编码风格，并使用像 Prettier 这样的代码格式化程序，将代码自动格式化为一种风格。不是每个人都可能不喜欢每种格式选择，但这没关系。花时间争论缩进的空格数量是不值得的。
- 作为代码的创建者，留下评论或链接到有意义的上下文. 我们都进行了更改，其中有一段代码乍一看似乎很奇怪。也许您必须实现一些非常奇怪的逻辑，直到您真正深入研究才有意义，或者您必须解决浏览器错误并应用奇怪的 CSS 技巧以使其看起来恰到好处。审查您的代码的人会看到这些奇怪的东西并询问它们。我喜欢主动评论我自己的代码审查，并提供指向文档/屏幕截图/等的链接，这些链接解释了代码为何如此（我经常在实际的代码评论中这样做，而不是在 GitHub 上的评论）。这并不意味着代码不能改进，但它节省了一些来回向审阅者解释的东西。如果审阅者有更多的上下文，他们可以花更少的时间弄清楚这一点，而花更多的时间思考你的方法以及它可能导致的任何潜在问题。
- 假设良好的意图。如果您正在查看一些代码并且您无法理解作者为什么会这样做，那么以下两种情况之一是正确的：作者是一个糟糕的开发人员，或者他们有一些您没有的上下文。希望它不太可能是前者！在确定该选项之前，他们可能已经尝试了其他三种方式，或者可能需要您误解的更改。永远不要害怕问清楚或检查你对某事的理解。我从我同事的代码更改中了解的代码库几乎与我通过自己进行更改所了解的一样多。
- 如果您要求更改或提出建议，请明确说明。大多数代码审查评论属于以下两类之一：您注意到但感觉不那么强烈的评论，或者您认为绝对应该在合并更改之前修复的评论。如果您可以在每条评论中明确说明您对此的感受有多强烈，并且如果这是一个建议，如果作者不同意，或者如果这是必须解决的问题，作者应该可以随意忽略。这样，当我的代码审阅你的人时，我可以很容易地看到最重要的评论并专注于这些评论，如果我不同意你的建议，或者当你留下我的评论时，我知道什么时候开始讨论可以选择忽略或不忽略。
我们肯定会在以后的博客文章中重新讨论代码审查的主题；它们是思考您正在编写的代码及其潜在混淆点的好方法（在我的脑海中，我喜欢思考“审阅者对此有何看法？”或“对于审阅此代码的人来说，什么是不明显的？ ?") 来帮助我改进我的代码。
