对拉取请求的有效评论

由 Mux 主办的 DEV 全球展示挑战赛：展示你的项目！

这篇文章并非教你如何撰写优秀的 pull request，因为本博客和网上已经有很多这方面的优质资料。这篇文章的重点在于如何对 pull request进行有效的评论。

我并非第一个提出这个话题的人。在我上次实习期间，我参加了一场精彩的讨论会，主题是“高效的代码审查”。讨论的重点在于代码审查者本身，而不是代码作者。

从那时起，我就想分享更多讨论内容。因此，我希望这篇文章能帮助你写出更好的评论，也能让我们更深入地探讨这个话题。

介绍

所以你可能会说：

“当我审核拉取请求时，我知道如何提出建设性的反馈意见。我绝不会这样写：

那我怎么可能像他那样高效呢？

首先，是的。请千万不要写那样的话。的确，明显的恶意行为很容易识别和避免。然而，有时我们可能会无意中用看似无害的建议伤害到彼此。

作为人类，我们无法逃避自己的本性。我们天生具有防御性。这就是我们大脑的运作方式。我们有自己的偏见、喜好和信仰，这很正常！

一个（并非）非常罕见的场景

也就是说，提交 pull request 的目的并非编写完美无瑕的代码，而是让我们（作者和审阅者）学习如何改进我们现有代码库的状态。
那么，在这个过程中，我们又该如何无意中损害我们的效率（以及我们自身）呢？

让我给你讲个故事：
两周后，你终于完成了PIE系统本次迭代中最受期待的功能。你花了无数个小时阅读代码，查找拼写错误，并尽可能地测试了所有功能。现在终于到了部署的时候，你向生产分支提交了一个PR。

你我同属一个团队，所以你把我添加为你的 PR 的审核人。然后，你去做别的事情，而我则在审核你的修改后才能批准。
你啜饮了一口咖啡，脸上不禁露出笑容。你成功了！经历了这么长时间，你终于可以庆祝了。

然而，三十分钟后，你发现我在你的 PR 下留了一些评论。你打开页面，看到以下内容：

假设这种情况再持续五六条评论，
你会作何感想？

你未必感到被冒犯……但你也感觉不太好……对吧？

相反，请看看我留下另一组评论的平行宇宙：
如果你读到这些评论，你会作何感想？

有效审查公关稿

多提问题，少提建议。

多问问题。在提出改进建议之前，你应该先理解代码的功能。这有助于实现两个目标：

• 你会了解更多关于代码的信息。
• 你可以帮助作者发现他们没有注意到的小错误。

PS：如果您私下讨论过某些事情，请记得添加更新，以便团队中其他可能有同样疑问的人也能知道讨论的内容。

你也可以留下赞美之词。

如果可以的话，我强烈建议你这样做。提交 Pull Request 不仅仅是为了指出需要改进的地方，你也可以指出一些积极的方面，例如：

如果变化太大的话

我们当然想编写出最好的代码，但有时也只能做到“足够好”。与其指出某些改动在特定时间范围内无法实现，不如直接说明即可。

不要隐藏答案

如果你要求进行某项改进，请说明如何才能实现。

尽量避免使用“你”这个称呼

这是一个小问题，但请记住，我们评判的是代码本身，而不是代码的作者。

结论

作为开发者，我们必须致力于营造多元化的环境，让不同的意见都能被倾听和尊重地讨论。
希望这些建议能帮助大家更好地进行代码审查。

如果你不完全同意这些观点也没关系。我很想听听你在评论区的想法。你们觉得呢？

这也是我在这篇博客上的第一篇文章，希望你们喜欢！

此致敬礼，
坦克雷多。