拉取请求很大时如何进行更好的代码审查？

免责声明：有一些类似的问题，但是在查看大型拉取请求时，我没有发现任何能特别解决您面临的问题的问题。

问题

我觉得我的代码检查可以通过更好的方式完成。我特别是在谈论大型代码审查，其中涉及20多个文件的许多更改。

捕获明显的本地代码问题非常简单。但是，了解代码是否符合业务标准是另外一回事。

我在遵循代码作者的思考过程时遇到了麻烦。当更改数量众多且分布在多个文件中时，这非常困难。我尝试着重于与特定更改相关的文件组。然后逐一查看组。不幸的是，我使用的工具（Atlassian Bitbucket）不是很有帮助。每当我访问文件时，即使经常证明它与当前检查的更改都不相关，它也会被标记为可见。更不用说一些文件应该被多次访问，并且它们的更改要逐个进行审查。当您走错路时，要返回相关文件也不容易。

可能的解决方案，以及为什么它们对我不起作用

通过提交复审拉取请求通常可以解决大小问题，但是我不喜欢它，因为我经常查看过时的更改。

当然，创建较小的拉取请求似乎是一种补救方法，但这是正确的，有时您会收到一个大的拉取请求，必须对其进行审查。

您也可以整体上忽略代码的逻辑方面，但这似乎很有风险，尤其是当代码来自没有经验的程序员时。

使用更好的工具可能会有所帮助，但我没有找到。

问题

• 您的代码审查是否遇到类似的问题？你如何面对他们？
• 也许您有更好的工具？

我们遇到了这些问题，并提出以下问题对我们来说一直很好：

PR是否做一件可以合并并且可以独立测试的事情？

我们尝试通过单一责任（SR）打破PR。经过最初的压抑，人们惊讶地发现即使是很小的东西也可以是很大的东西。

SR使审查变得非常容易，并且还传播了有关预期实施的知识。

随着增加的数量，PR的周转时间也大大减少，这也允许增量重构！

我建议，如果可能的话，请通过SR分手，看看是否对您有用。采取一些练习来做到这一点。

有时您无法避免大量的拉动请求-但是您可以确定谁负有什么责任。

我将请求请求视为有说服力的论点。作者试图使我相信代码应该以这种方式运行。

与任何论点一样，它应该有一个明确的想法。它要么：

• 重构
• 优化，
• 或新功能。

如果他们不清楚，那么很有可能他们自己不理解。打开对话，并帮助他们将论点分解为子论点。如果需要的话，它是完全正确的-甚至对他们重新创建那些提交并提供更多可理解和直接的拉取请求也很有帮助。

仍然会有大量的请求请求，但是有了明确的论据，它很容易发现不合适的请求。

至于工具，它取决于您的组织和过程。BitBucket是一个不错的工具，它的好坏取决于预算，硬件，要求，再到现有流程，业务规则以及为适应BitBucket而进行的各种软件改编。我将首先浏览文档，以了解行为是否可以配置，也许扔掉到插件社区（或通过制作插件加入插件社区来做到这一点）。

不要查看完整的请求请求，但要检查每次提交。通过这种方式，您无论如何都会对拉取请求有更好的了解。¹

如果提交量很小，那么进行此类审查应该不是问题。您通过提交操作逐一跟踪更改，最终获得了全貌。有缺点，例如您有时会回顾一些更改，这些更改在以后的一些提交中将被撤消，但这不是很多。

如果提交量很大，那么您应该与进行这些提交的人讨论。向他解释为什么大型提交会带来问题。听别人关于他为什么提交变更的争论很少：例如，您可能会学到，他避免执行提交，因为预先提交的钩子花费的时间太长，在这种情况下，应首先解决此问题。

通过提交复审拉取请求通常可以解决大小问题，但是我不喜欢它，因为我经常查看过时的更改。

您确实这样做了，但这是一个小问题，与检查一个文件时为什么要弄清楚为什么更改代码的时间相比，您应该花更少的时间查看代码，而在撤消几次提交后，您将被撤消。

“经常”是含糊的，但是如果您发现自己花费过多的时间来审查未能找到拉式请求最终修订版的代码，则可以使用两种技术：

• 快速浏览所有提交一次，仅阅读提交消息。这样，在研究特定的提交时，您可能还记得，某处的提交消息后来说您正在查看的更改已还原。

• 并排查看文件的最新版本（尽管在许多情况下，对于大型提交，（1）文件可能有根本不同，并且（2）文件可能会被重命名，或者大块代码可能移到其他位置，很难找到匹配的文件）。

• 要么要求提交者在有意义的时候压缩提交，要么制定特定的提交消息约定，其中一个提交撤消另一提交的一部分，并考虑以下几个提交来进行审核。

^{¹例如，假设您正在查看一个文件，其中某些变量已被重命名。它告诉你什么？您应该如何查看此更改？但是，如果按提交逐一检查它，您会看到单个提交在二十个文件中重命名了相同的变量，并且注释指示名称已更改，以便使用正确的业务术语。此更改非常合理，可以复查。}

通过查看拉取请求来确定您要实现的目标，并查看是否有其他选择。

例如，您可能想要

• 确保遵循标准
• 检查功能是否正确
• 确保不止一个人能理解代码
• 初级培训

等等等

其中的某些方法可以通过其他方式更好地解决，甚至仅了解原因也可以限制检查范围。

例如，如果我正在检查每一行，以便我可以建议和讨论培训方面的变化，那么我可以在老年人进行的大型公关活动中跳过

如果我需要理解代码，也许可以对大型功能进行配对编程，并将代码审查限制为标准检查。

只要您采用分层的质量检查方法，就无需检查每个PR上的所有内容