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