我如何进行代码审查

今天，我的虚拟咖啡社区有人问到如何改进 PR 的审核，于是我就写了这篇文章。希望你能从中找到一些有用的信息。如果你觉得有用，我很乐意听取你的意见！如果你觉得没用，也没关系。欢迎提出改进我流程的建议！

首先，我会阅读标题和描述，了解具体内容。如果其中引用了问题或其他 PR，我会查看它们以了解更多背景信息。如果用户界面 (UI) 有变化，我会查看前后截图。如果没有截图，但 UI 有变化，我会要求审核人员提供一些截图。这样可以更轻松地从总体上评估变化。

好了！我们来运行代码测试一下吧！哇，还没到时候。

接下来，我开始浏览所有修改过的文件。如果文件修改太多，PR 审核就会变得非常繁琐。

一般来说，PR 应该较小，原因如下：

有时别无选择，只能提交一个相当大的 PR。我主要在 UI 工作中见过这种情况，但它也适用于后端工作，通常是一个要么全有要么全无的场景。

如果上述情况不成立，那么我认为 PR 臃肿的原因如下：

如果有人发现他们可以做的重构或错误修复，但这些与 PR 无关，请他们将这些内容放入单独的 PR 中，并将 PR 与手头的任务关联起来。
待完成的工作不会被分解。请专注于推进更复杂的工作。例如，一个贯穿整个功能始终的实用函数可以放在一个单独的 PR 中。如果用户正在构建新的 UI，他们可以独立构建组件，并提交另一个 PR，并可能使用Storybook之类的工具来构建它们。

请记住，问题或功能不需要映射到一个 PR。

最后，我查看了一些代码！我会搜索那些让我感到突出的问题，而无需拉取 PR 并在本地运行代码。我这里指的不是格式/编码风格问题，因为现在很多项目都有像 linters 或代码格式化程序这样的工具。

我寻找的东西：

在某些情况下，可能会出现编码风格的问题，例如，当函数或方法的条件不成立时，需要提前返回。如果在审核过程中发现可以自动更改的变更，那就自动化处理吧！不过，最好在单独的 PR 中处理。😎

第一次审核代码后，如果有变更请求，我会把 PR 发回给被审阅者。等等？你还没运行代码吗？作为审阅者，我也有自己的工作要做，所以我先不去测试一下 PR。

初步审核后，我会检查所做的更改和反馈。我可能会提供更多反馈。一旦（暂时）没有剩余更改，我会拉取代码并在本地运行。根据项目的设置，它可能会在 Netlify 或 Vercel 等主机或某些容器化环境中为 PR 提供预览部署以供测试。无论如何，现在是时候验证 PR 的意图了。

此时，很可能仍会有审核反馈，因此我会继续审核变更并确保 PR 的意图。根据工作内容，审核过程可能需要一些时间；时区差异可能会延长审核时间。掌握异步沟通技巧至关重要，尤其是在现在许多科技行业正在/已经转向远程办公文化的当下。

最后，评论的语气很重要。我已经习惯使用一种名为“常规评论”的评论框架。如果你想了解更多，我去年就“常规评论”做了一个简短的演讲。Netlify 创建了一个类似的系统，名为“反馈阶梯”。查看 Leslie 的推文了解更多信息。

2022年4月更新：我现在在 Netlify 工作，所以开始使用 Feedback Ladders。目前为止，我很喜欢它。

如果你做到了这一步，你的 PR 就被批准了！😎

谢谢，下次再见！

您还可以在其他地方找到我：