How Developers Use Relation Chains in Gerrit-Based Review Ecosystems: An Empirical Study Across Three Open-Source Ecosystems

想象一个构建软件就像建造一座宏伟、复杂城堡的世界。在这个世界里，开发者不仅仅是把砖块扔向墙壁并祈祷它们能粘住；他们使用一套严密的系统，称为代码审查（Code Review）。在任何新砖块（或代码行）被永久添加到城堡之前，都会有一组检查员检查它是否有裂缝，确保它符合设计要求，并确保它不会破坏其他部分。这个过程对于保持城堡屹立不倒且安全至关重要。

然而，有时一个项目不仅仅是一块砖，而是一整座塔楼。在过去，开发者可能会尝试一次性建造整座塔楼，但那样很难进行检查。因此，他们开始将其分解为一系列较小的、相互连接的步骤。在软件领域，特别是在一个名为 Gerrit 的工具中，这些相连的步骤被称为关系链（Relation Chains）。把关系链想象成一排站立的多米诺骨牌：虽然你不能在第二个倒下之前推倒第三个，也不能在第一个倒下之前推倒第二个，但检查员可以同时检查所有骨牌，但城堡只能按顺序完成。整个链条是相互关联的；如果第一个骨牌（“基础”）不稳，整个序列都会陷入麻烦。理解这些链条如何运作至关重要，因为如果系统太慢或太混乱，开发者可能会陷入数小时的等待，或者城堡可能会带着隐藏的裂缝被建成。

---

多米诺效应：开发者实际上是如何使用代码链的

本文深入探讨了三个大型开源社区（OpenStack、Wikimedia 和 ONAP）中的开发者如何使用这些“关系链”来构建软件。研究人员调查了近 30,000 个链和超过 400,000 个独立的代码变更，以观察这些相互关联的骨牌在现实世界中是如何表现的。他们想知道：这些链条常见吗？它们会让审查过程变快还是变慢？当你试图修复链条中间的一个骨牌时会发生什么？

链条无处不在（且规模在扩大）

首先，研究发现这些链条并不是一种罕见的、小众的技巧；它们是一种标准的工作方式。根据项目的不同，5% 到 49% 的所有代码变更都是链条的一部分。事实上，在他们研究的 15 个项目中，有 14 个项目的这种链条使用量实际上是随时间增加的。开发者意识到，将大任务分解为相互关联的小块是正确的做法。

大多数这类链条都很短，通常只是两个骨牌（一个基础变更和一个依赖变更）。然而，有些项目的链条延伸得极其深。研究人员发现了长达 98 个成员的链条！甚至有一个项目包含了一个拥有近 60,000 个成员的自动生成链条，不过那是自动化配置的特例，而非人工编写。

“中间”是瓶颈所在

这里是变得有趣的地方。研究人员发现，处于链条中间是最难的工作。如果你是第一个骨牌（“基础”），你只需要等待你自己的审查。如果你是最后一个（“顶部”），你只需要等待前面的部分。但如果你处于中间，你就陷入了挤压。你被前面的骨牌所阻碍（等待它被批准），同时又在阻碍后面的骨牌。

由于这种“挤压”，链条中的变更在获得批准方面要花费显著更多的时间。研究发现，平均而言，链条成员的合并时间比同等规模的单个、独立变更要长 2.6 倍。这种延迟并不是因为代码质量变差，而是因为“同步开销”。尽管检查员（审查者）可以并行检查砖块，但实际合并到城堡中必须是一个接一个、由下而上进行的。每当链条中的一个变更进行微调时，往往会迫使整条线进行重新检查、重新测试和重新排序，从而产生一个瓶颈：中间的变更在等待下方的变更时，同时也拖累了上方的变更。

“CI 放大”怪兽

论文还强调了一种他们称之为 CI 放大效应的现象。“CI”指的是持续集成（Continuous Integration），这就像一支机器人军队，会自动测试每一块新砖，以确保它不会破坏城堡。在规则严格的项目（如 OpenStack）中，每当开发者更新链条中的一个变更时，机器人军队都必须重新测试该变更以及所有依赖于它的变更。

研究发现，链条成员会触发 10 到 23 个自动化测试作业，而单个、独立的变更可能仅触发少于两个。这就像是你每换一个灯泡，就不得不重新测试你的整个房子一样。这为计算机带来了巨大的额外工作量，也造成了人类的延迟。

“基础效应”

作者们发现的一个最引人入胜的发现是他们所谓的基础效应（Foundation Effect）。他们发现，在第一个骨牌（基础）上投入的精力预示了随后所有骨牌将投入的精力。

如果基础变更获得了大量的关注、许多评论和多轮修订，那么整个链条往往也会随之如此。研究人员发现，基础变更的活跃度与后继变更的活跃度之间存在很强的联系（相关系数为 0.43 到 0.61）。这就像是第一个骨牌的“氛围”为整条线定下了基调。如果基础不稳且需要大量修复，那么整座塔楼的建造就会更慢。相反，如果基础坚实并能快速获得批准，其余的链条往往会顺畅流动。

链条并非静态

最后，论文揭示了这些链条并非僵化的结构。大约 33.5% 的链条中的变更在最终合并之前经历了“结构演化”。这意味着骨牌之间的连接在被审查期间是在发生变化的。开发者可能会决定将一个变更从其父项脱离，并将其链接到另一个不同的项，或者整个链条可能会被重组。

这增加了另一层复杂性：链条的地图在不断变化。有时，一个链条可能会处于长期停滞状态。研究发现，在某些情况下，一个链条部分的提交时间与它最终合并之间的时间间隔可以长达 2.85 年！

这对未来意味着什么

作者总结道，目前的代码审查工具通常将每次变更视为一个孤立的事件，就像只看单块砖头而不看它所属的墙壁一样。这篇论文表明，我们需要改变工具，以将“链条”作为一个整体单元来理解。

他们建议，如果我们把注意力集中在链条的基础（第一个骨牌）上，我们可以为整个链条节省大量时间。如果基础是稳固的，整个结构就会移动得更快。他们还提出，工具应该对“中间”的变更更加智能，例如优先处理它们，以解除剩余部分的阻塞。

简而言之，使用关系链构建软件就像指挥一场复杂的交响乐。如果指挥家（基础）节奏不对，整个乐队都会挣扎。但如果指挥家清晰，且乐器（工具）理解乐器之间的联系，音乐就会流动得更快。这项研究表明，通过理解这些连接，我们可以停止排队等待，开始更高效地建造城堡。