你认为延迟代码审查的最典型原因是什么？Google的一项研究确认了这一点：规模越大，审查就越慢。另一项研究表明，情绪态度是原因之一：评论中表达的愤怒和支配性与代码审查通过的可能性较低有关。最近的一项研究发现，作者的声誉也是一个因素：如果我们了解作者，我们会更快地合并代码。总结以上三点都是正确的。然而，在我们的项目中，经常导致代码审查变慢的原因是这样的信息：“CI失败与我的更改无关！”
具体情况是这样的：你fork了一个仓库。你进行了更改以修复错误或引入新功能。你提交了更改并推送到仓库。你提交了一个pull request。你发现一些GitHub CI任务失败了。你阅读日志，却看不到错误信息与你的更改之间的关联。你发表了评论：“CI失败与我的更改无关！”你希望我们合并你的pull request。
我们不会合并它们。我们要求您退后一步—回到您开始进行更改之前的状态。暂时不要进行更改。相反，检查存储库的构建状态。注意所有CI作业，而不仅仅是运行Maven的作业。它们全部必须是绿色的。只有当所有作业都是绿色时，您才可以开始编辑代码。如果任何作业是红色的，请报告错误并等待团队解决所有问题。
为什么？因为我们试图减少修复构建所需的工作量。我们对一个破损的构建堆积越多更改，清理的成本就越高。当构建破损时，我们不接受任何新更改—除非是用来修复构建的更改。
如果团队花费太长时间来修复它怎么办？如果构建永远无法变成绿色怎么办？仍然—您需要等待。不要将拉取请求提交到一个破损构建的存储库。
你可以自己修复构建问题。如果你这样做，请将其提交到一个独立的拉取请求中。不要将构建修复更改与其他编辑混合在一起。
Translated by ChatGPT gpt-3.5-turbo/42 on 2025-04-21 at 08:32
