The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
当你从别人那里审查一个拉取/合并请求时，你会检出分支并运行构建吗？我通常不会，但是有些人会。他们的明显理由是：运行构建，甚至手动测试产品，有助于发现更重要的错误。仅仅查看源代码可能无法揭示最近在HTML/CSS中引入的所有视觉缺陷，例如。最好检出分支，启动Apache，在Chrome中打开网站，看看有什么问题。然后，截屏，附加到拉取请求中，并将其返回给作者。但是我不同意这个观点，以下是原因。
这个讨论并不新鲜，在SO上可以查看这个和这个。然而，似乎所有答案都没有抓住关键点。
众所周知，在任何软件项目中，存在两个冲突的角色：构造者和破坏者，也称为程序员和测试人员。程序员添加新功能并修复错误。他们的结果是所创建的功能数量：越多越好。而测试人员正在破坏产品并报告错误，尽其所能证明产品还没有准备好交付给客户。在某个时间点，团队（或管理层）决定这场争斗结束了，产品可以交付。
由于这个本质上的冲突，质量得以实现。
程序员在代码通过合并流水线时完成他们的工作：更改在他们的笔记本电脑上完成，单元测试在本地通过，静态分析不报错，构建干净，分支合并到主干。这是程序员停下来并获得奖金的地方。
测试人员在成功找到部署到暂存或生产环境的产品中的新缺陷时完成他们的工作：发现了错误，报告并被项目接受。这是测试人员停下来并获得奖金的地方。
这是显而易见的。如果不是，请阅读Glenford Myers的《软件测试艺术》或Yegor Bugayenko的《Code Ahead》。您还可以观看这个视频。
那么，在这场争斗中，代码审查员的位置在哪里？
我认为，代码审查是合并流水线的一部分，与单元测试、静态分析器、代码检查工具、突变测试器以及项目可能希望放入其中的所有其他内容一起，以使程序员的生活更加困难，源代码的质量更高。合并流水线的目标是保护代码库免受程序员的侵害。
代码审查员与代码检查工具或静态分析器没有什么不同：他们阻止有问题的代码分支进入主干。当他们阻止时，他们会给出理由。他们的工作（类似于代码检查工具）完成时，他们成功在分支中找到问题并解释它们。当代码审查员找到有问题的行并解释问题并提出解决方案时，这正是他们必须做的。
这就是代码审查员应该得到报酬的原因：完成的审查。
什么是完成的审查？“一切都正常”听起来像是完成的审查吗？对于代码检查工具-是；对于代码审查员-不是。这个更好一些：“我找到了三个问题，解释了它们，并且它们要么被讨论，要么被修复。”这是代码审查员的工作描述可能听起来的样子：找到三个最关键的问题，解释它们，并确保它们要么被修复，要么被正确争论。
代码审查员发现这三个问题的方式有很多。他们可以对代码进行视觉检查或运行构建。然而，当他们成功找到问题并确保代码的作者理解问题并修复问题或解释为何问题无法修复（或不是问题）时，他们仍然会被支付报酬。对代码进行视觉检查很快，而检出分支并运行构建则是一个更耗时的操作。此外，运行构建后发现的错误在代码审查格式中很难解释。与分支作者的讨论将需要更长时间，这意味着完成代码审查所需的时间更长，这意味着代码审查员的效力降低。
我的观点是聪明的代码审查员不这样做，因为这样做效率低下。请注意，他们之所以不这样做并不是因为他们不在意，而是因为他们了解更好的贡献项目的方式。面对现实吧，当我们面前的分支通过诸如代码检查工具和单元测试之类的所有自动化检查时，但仍然存在一些我们只能通过执行代码才能复现的错误时，我们的自动化测试就有问题了。一个高效、负责任且贪婪的代码审查员不会向代码的作者解释问题所在。相反，将创建一个新的错误，责怪合并流水线太弱。当然，这个新的错误将得到奖赏。
因此，作为代码审查员，你可以在本地使用这个分支，对其进行测试并将你的发现报告给作者。但这将违背你的个人利益，对项目也没有好处。相反，你应该向项目投诉自动化测试的质量低下，并将审查暂停。当投诉得到解决时，测试变得更加强大，你就可以继续审查，这次审查将被合并流水线拒绝，而不是被你拒绝。
在这种情况下，每个人都是赢家：流水线变得更强大，你因报告的错误获得额外的奖金，审查被拒绝，并给出一个非常具体的可重现的理由。
附注：此博文的灵感来自Robert Sösemann。
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-11-17 at 17:04
