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

ソフトウェアの構築が、巨大で複雑な城を築き上げることに似ている世界を想像してみてください。この世界では、開発者はただ壁にレンガを投げつけてくっつくのを祈るわけではありません。彼らはコードレビューと呼ばれる厳格なシステムを使用します。新しいレンガ（あるいはコードの行）が城に永久に組み込まれる前に、検査チームがひび割れがないか、設計に適合しているか、そして他の部分を壊していないかをチェックします。このプロセスは、城を高く、安全に維持するために不可欠です。

しかし、時にはプロジェクトが単一のレンガでは収まらないこともあります。それは一つの「塔」を建てるようなものです。かつて、開発者は塔全体を一度に作ろうとすることもありましたが、それでは検査が困難でした。そこで、彼らは作業を、一連の小さく連結されたステップへと分解し始めました。ソフトウェアの世界、特にGerritというツール内では、これらの連結されたステップは**リレーションチェーン（Relation Chains）**と呼ばれます。リレーションチェーンを、並んだドミノの列だと考えてみてください。二番目のドミノが倒れない限り三番目は倒れませんし、一番目が倒れない限り二番目も倒れません。しかし、検査官はこれらすべてを同時にチェックできますが、城の完成は順番通りに進める必要があります。チェーン全体は連結されています。もし最初のドミノ（「ベース」）が不安定であれば、ライン全体が危険にさらされます。このチェーンの仕組みを理解することは極めて重要です。なぜなら、システムが遅すぎたり混乱したりすると、開発者が何時間も待たされることになったり、城に隠れたひび割れが生じたまま完成してしまったりする可能性があるからです。

---

ドミノ効果：開発者が実際にコードチェーンを使用する方法

この論文は、3つの大規模なオープンソースコミュニティ（OpenStack、Wikimedia、ONAP）において、開発者がソフトウェアを構築するためにこれらの「リレーションチェーン」をどのように使用しているかを深く掘り下げたものです。研究者たちは、約3万件のチェーンと40万件以上の個別のコード変更を調査し、これらの連結されたドミノが現実の世界でどのように振る舞うのかを調べました。彼らが知りたかったのは次の点です。これらのチェーンは一般的なのか？ レビュープロセスを速くするのか、それとも遅くするのか？ そして、列の途中のドミノを修正しようとすると何が起きるのか？

チェーンは至る所にあり、（そして大きくなっている）

第一に、本研究は、これらのチェーンが珍しいニッチなテクニックではなく、標準的な作業方法であることを明らかにしました。プロジェクトによりますが、すべてのコード変更の5%から49%がチェーンの一部となっています。実際、調査対象となった15のプロジェクトのうち14のプロジェクトにおいて、これらのチェーンの使用は時間の経過とともに増加しています。開発者は、大きなタスクを連結された小さな断片に分解することが最善の方法であると気づきつつあるのです。

ほとんどのチェーンは短く、通常は一対のドミノ（ベースとなる変更と、それに依存する一つの変更）で構成されています。しかし、プロジェクトによっては、信じられないほど深いチェーンを持つものもあります。研究者たちは、最大98個のメンバーを持つチェーンを発見しました。あるプロジェクトでは、自動生成されたチェーンが6万近くのメンバーを持っていましたが、これは自動設定による特殊なケースであり、人間が書いたものではありませんでした。

「中間」がボトルネックになる

ここからが興味深いところです。研究者たちは、チェーンの「中間」にいることが最も困難な仕事であることを発見しました。もしあなたが最初のドミノ（「ベース」）であれば、自身のレビューを待つだけです。もしあなたが最後（「トップ」）であれば、前の工程を待つだけです。しかし、もしあなたが中間にいるとしたら、あなたは挟み撃ちに遭います。あなたは前のドミノ（承認されるのを待つ）によってブロックされている一方で、同時に後ろのドミノたちをブロックしているのです。

この「挟み撃ち」のため、チェーンの中間の変更は承認されるまでに著しく時間がかかります。研究によると、チェーンのメンバーは、同サイズの孤立した単独の変更と比較して、マージまでに平均で2.6倍長くかかっています。この遅延は、コードの質が悪いせいではなく、「同期オーバーヘッド」によるものです。検査官（レビュアー）は各レンガを並行してチェックできますが、城への実際のマージは、下から上へと一つずつ順番に行われなければなりません。チェーン内の変更が修正されるたびに、多くの場合、ライン全体を再チェック、再テスト、再配置する必要があり、これがボトルネックを生み出します。つまり、中間の変更は下の変更を待っている間に、上の変更を足止めしてしまうのです。

「CI増幅」という怪物

この論文は、彼らがCI増幅効果と呼ぶ現象についても強調しています。「CI」とは継続的インテグレーション（Continuous Integration）のことで、新しいレンガが追加されるたびに、それが城を壊さないかを自動的にテストするロボット軍団のようなものです。厳格なルールを持つプロジェクト（OpenStackなど）では、開発者がチェーン内の変更を更新するたびに、ロボット軍団はその変更と、その変更に依存するすべての変更を再テストしなければなりません。

研究によると、チェーンのメンバーは10から23の自動テストジョブをトリガーしますが、単独の孤立した変更であれば、トリガーされるのは2つ未満であることが多いです。これは、たった一つの電球を取り替えるたびに、家全体の再テストを強制されているようなものです。これにより、コンピュータに膨大な追加作業が発生し、人間に対する遅延が生じます。

「基礎効果（Foundation Effect）」

著者たちが**基礎効果（Foundation Effect）**と呼ぶ、最も魅力的な発見の一つがあります。彼らは、最初のドミノ（ベース）に費やされた労力が、その後のすべてのドミノに費やされる労力を予測することを発見しました。

ベースとなる変更に多くの注目が集まり、多くのコメントや多くの修正ラウンドが行われると、チェーン全体がその傾向に従うことになります。研究者たちは、ベースにおける活動と、その子孫（後続の変更）における活動との間に強い関連性（相関関係 0.43から0.61）があることを発見しました。それはまるで、最初のドミノの「雰囲気」がライン全体のトーンを決めるかのようです。もし基礎が不安定で、多くの修正を必要とするならば、塔全体の構築には時間がかかります。逆に、ベースが堅実で迅速に承認されれば、残りのチェーンはスムーズに流れる傾向があります。

チェーンは静的なものではない

最後に、この論文は、これらのチェーンが硬直した構造ではないことを明らかにしています。チェーン内の変更の約**33.5%**が、最終的にマージされる前に「構造的進化（structural evolution）」を経験します。これは、レビューされている間に、ドミノ同士の接続関係が変わることを意味します。開発者が、ある変更を親から切り離して別のものにリンクさせたり、あるいはチェーン全体が再編成されたりすることもあります。

これはさらなる複雑さをもたらします。チェーンのマップは常に変化しているのです。時には、チェーンが長い間休止状態になることもあります。研究では、あるチェーンの一部が提出されてから最終的にマージされるまでの期間が、ケースによっては最大2.85年に及ぶことも分かりました。

これが将来にとって何を意味するか

著者たちは、現在のコードレビュー用のツールは、壁の一部としての繋がりを見ることなく、個々の変更を孤立したイベント（単一のレンガ）として扱っていることが多いと結論付けています。この論文は、チェーンを一つのユニットとして理解するように、ツールを変える必要があることを示唆しています。

もし私たちがチェーンのベース（最初のドミノ）に注意を集中させることができれば、残りのチェーンの時間を大幅に節約できると彼らは提案しています。もし基礎がしっかりしていれば、構造全体がより速く動きます。また、彼らはツールが「中間」の変更に対してももっと賢くなるべきであり、例えば、残りのラインの停滞を解消するために、中間部分の優先順位を上げるべきであるとも提案しています。

要するに、リレーションチェーンを用いてソフトウェアを構築することは、複雑なオーケストラを指揮することに似ています。もし指揮者（ベース）のテンポが狂えば、オーケストラ全体が苦戦します。しかし、もし指揮者が明確で、演奏者（ツール）が楽器同士の繋がりを理解していれば、音楽はもっと速やかに流れます。この研究は、これらの繋がりを理解することで、私たちは列に並んで待つことをやめ、より効率的に城を築き始めることができるということを示唆しています。