我正在改变我审查代码的方式

我非常提倡代码审查。我写过很多我审查代码的经验，包括哪些该做哪些不该做、如何在第一次代码审查中顺利通过，以及我们为什么要进行代码审查。

我的观点主要源于我参与一种特殊代码审查方式——拉取请求 (Pull Request) 的经验。和许多开发者一样，我已经习惯了使用拉取请求模式来促进代码审查。虽然它并不完美，但我一直认为它是一个很棒的工具，总体来说，它比正式的代码审查流程或电子邮件审查有所改进。

然而，最近我看到了一些表达不同情绪的想法。许多开发者开始对拉取请求模型感到沮丧。他们觉得拉取请求实际上可能会让对一行代码的评论变得过于容易。这种便利可能会导致冲突和过度狂热的评论，这让我们这个行业的许多人感到沮丧。

另一个常见的批评是，拉取请求鼓励审阅者只看代码。他们甚至从不拉取他们正在审阅的更改！坦白说，我自己也犯过这种错误。

读完这篇文章，又在推特上看到一些相关的想法后，我开始思考：有没有更好的方法来审查代码？我可以做些什么不同的事情？

经过咨询后，我决定开始改进我的代码审查方式。他们最近一直在帮助我，所以我认为他们也能帮助到你和你的团队。

评论代码 vs. 协作代码

让我开始质疑我如何审查代码的一个主要想法来自上面的文章：

拉取请求对于单独工作来说是一种进步，但对于团队合作来说则不然。

这引起了我的共鸣。确实，拉取请求 (Pull Request)并不是人们协作的主要方式。

代码协作对于团队维护代码库的能力至关重要。如果团队中只有一名成员独自编写整个代码库，而没有与其他成员合作，那么团队其他成员很可能在一段时间后无法为其做出贡献。更糟糕的是，如果任其发展，单个成员甚至可能会出错或无法解决问题。因此，尽早并经常进行协作是一个好主意。

接下来的问题是：团队如何协作编写代码？此外，团队协作是否会过早？过于频繁？

许多团队似乎都认为拉取请求 (Pull Request) 是协作的绝佳平台。我认为他们没错。首先，团队成员准备好与其他成员分享他们的代码版本以获得直接反馈。然后，就像作者写书一样，他们提交代码进行初审以获得反馈。其余成员则充当编辑，随时准备协助完成草稿的印刷。

团队将拉取请求视为协作平台本身并没有错。问题在于团队是否认为协作仅限于代码审查流程。

在提交代码进行评审之前，团队应该就问题、想法和代码展开合作。导师应该为学员提供建议，同学应该互相帮助，结对编程或调试会议应该成为常规活动。如果作者在未透露书的内容的情况下将初稿发送给编辑，编辑的工作就会更加困难。编辑现在需要了解更多内容才能提供有用的反馈。因此，出版日期很可能会比预期推迟。

真正的协作不仅仅是留下评论或建议。它还包括讨论替代方案、提出需求，并与团队进行实时反馈。

我会努力让这种协作方式在我的团队中更加普及。我希望我们能够超越仅仅通过评论进行协作，回归实时协作。

在没有运行或单步执行任何更改的情况下就评论并拒绝拉取请求，如果直接说出来听起来很傻。但很多开发者——包括我！——一直都是这样做的。

作为工程师，我们不应该仅仅通过代码的“简洁”程度或抽象程度来评估它。相反，我们仍然需要衡量代码在预期功能上的表现——即在运行时提供的价值。

为了进一步说明这一点，你上次查看谷歌搜索的源代码是什么时候？如果你看到了，它会改变你对它作为一款产品运行良好程度的看法吗？可能不会。

我并不是想在这里过度简化。代码质量确实很重要！它应该干净、清晰、可变等等。

但代码好不好，部分原因在于它解决问题的能力。它是否满足了需求？最终产品会更好吗？至少，所有代码都需要让最终产品更好。

要检验代码是否能提升产品体验，最好的方法是什么？你必须运行它。把拉取请求当作一个机会，来演示新增或修复的功能。使用它，测试它，甚至亲自测试一下！

我对此感到非常内疚。我倾向于相信我们的自动化系统，认为代码更改会产生预期的行为变化，而我自己却没有观察到这些行为！我想开始改变这一点，更频繁地运行代码。