論文の概要: Repeated Builds During Code Review: An Empirical Study of the OpenStack
Community
- arxiv url: http://arxiv.org/abs/2308.10078v1
- Date: Sat, 19 Aug 2023 17:45:03 GMT
- ステータス: 処理完了
- システム内更新日: 2023-10-23 13:30:38.934481
- Title: Repeated Builds During Code Review: An Empirical Study of the OpenStack
Community
- Title（参考訳）: コードレビュー中の繰り返しビルド - OpenStackコミュニティに関する実証的研究
- Authors: Rungroj Maipradit, Dong Wang, Patanamon Thongtanunam, Raula Gaikovina
Kula, Yasutaka Kamei, Shane McIntosh
- Abstract要約: コミュニティから66,932のコードレビューの実証的研究を行った。
i)コードレビューの55%はビルド失敗後にリチェックコマンドを起動し、(ii)リチェックコマンドの呼び出しはビルド失敗の結果を42%のケースでのみ変更し、(iii)リチェックコマンドの呼び出しは平均2200%のレビュー待ち時間を増大させる。
- 参考スコア（独自算出の注目度）: 11.289146650622662
- License: http://arxiv.org/licenses/nonexclusive-distrib/1.0/
- Abstract: Code review is a popular practice where developers critique each others'
changes. Since automated builds can identify low-level issues (e.g., syntactic
errors, regression bugs), it is not uncommon for software organizations to
incorporate automated builds in the code review process. In such code review
deployment scenarios, submitted change sets must be approved for integration by
both peer code reviewers and automated build bots. Since automated builds may
produce an unreliable signal of the status of a change set (e.g., due to
``flaky'' or non-deterministic execution behaviour), code review tools, such as
Gerrit, allow developers to request a ``recheck'', which repeats the build
process without updating the change set. We conjecture that an unconstrained
recheck command will waste time and resources if it is not applied judiciously.
To explore how the recheck command is applied in a practical setting, in this
paper, we conduct an empirical study of 66,932 code reviews from the OpenStack
community.
We quantitatively analyze (i) how often build failures are rechecked; (ii)
the extent to which invoking recheck changes build failure outcomes; and (iii)
how much waste is generated by invoking recheck. We observe that (i) 55% of
code reviews invoke the recheck command after a failing build is reported; (ii)
invoking the recheck command only changes the outcome of a failing build in 42%
of the cases; and (iii) invoking the recheck command increases review waiting
time by an average of 2,200% and equates to 187.4 compute years of waste --
enough compute resources to compete with the oldest land living animal on
earth.
- Abstract（参考訳）: コードレビューは、開発者が互いの変更を批判する一般的なプラクティスである。
自動ビルドは低レベルの問題(構文エラーや回帰バグなど)を識別することができるため、ソフトウェア組織がコードレビュープロセスに自動ビルドを組み込むことは珍しくない。
このようなコードレビューデプロイメントシナリオでは、提案された変更セットは、ピアコードレビュアーと自動ビルドボットの両方によって統合するために承認されなければならない。
自動ビルドは変更セットの状態(例えば ``flaky'' や非決定的実行動作による)の信頼性の低いシグナルを生成する可能性があるため、Gerrit のようなコードレビューツールは、開発者は変更セットを更新せずにビルドプロセスを繰り返す '`recheck''' を要求することができる。
制約のない再チェックコマンドは、適切に適用されない場合、時間とリソースを浪費するだろうと推測する。
本稿では,OpenStackコミュニティによる66,932のコードレビューに関する実証的研究を行う。
定量的に分析する
(i)ビルド失敗の頻度を再確認すること。
二 再確認の実施が失敗の結果を左右する程度
(iii)再検査による廃棄物発生量
私たちはそれを観察する
(i)コードレビューの55%は、ビルド失敗が報告された後に再チェックコマンドを実行します。
(ii)再チェックコマンドを起動することは、ケースの42%で失敗したビルドの結果を変えるだけであり、
(iii)再チェックコマンドを起動すると、レビュー待ち時間が平均2,200%向上し、地球上で最も古い陸生動物と競うために、余剰廃棄物の計算資源が187.4年計算される。
関連論文リスト
- Deep Learning-based Code Reviews: A Paradigm Shift or a Double-Edged Sword? [14.970843824847956]
私たちは、自動生成されたコードレビューのサポートなしで、異なるプログラムをレビューする29人の専門家による制御された実験を実行しました。
本研究は,LLMが自動認識する問題の大部分をレビュアが有効とみなし,自動化されたレビューを出発点として利用できることが,彼らの行動に強く影響していることを示す。
しかし、自動化されたレビューから始まったレビュアーは、完全な手作業のプロセスと比較して、より高重度な問題を特定できない一方で、より多くの低重度な問題を特定した。
論文 参考訳（メタデータ） (2024-11-18T09:24:01Z) - Understanding Code Understandability Improvements in Code Reviews [79.16476505761582]
GitHub上のJavaオープンソースプロジェクトからの2,401のコードレビューコメントを分析した。
改善提案の83.9%が承認され、統合され、1%未満が後に復活した。
論文 参考訳（メタデータ） (2024-10-29T12:21:23Z) - Codev-Bench: How Do LLMs Understand Developer-Centric Code Completion? [60.84912551069379]
Code-Development Benchmark (Codev-Bench)は、細粒度で現実世界、リポジトリレベル、開発者中心の評価フレームワークです。
Codev-Agentは、リポジトリのクローリングを自動化し、実行環境を構築し、既存のユニットテストから動的呼び出しチェーンを抽出し、データ漏洩を避けるために新しいテストサンプルを生成するエージェントベースのシステムである。
論文 参考訳（メタデータ） (2024-10-02T09:11:10Z) - CodeRAG-Bench: Can Retrieval Augment Code Generation? [78.37076502395699]
検索拡張生成を用いたコード生成の系統的,大規模な解析を行う。
まず、コード生成タスクの3つのカテゴリを含む総合的な評価ベンチマークであるCodeRAG-Benchをキュレートする。
CodeRAG-Bench上のトップパフォーマンスモデルについて、1つまたは複数のソースから検索したコンテキストを提供することにより検討する。
論文 参考訳（メタデータ） (2024-06-20T16:59:52Z) - Leveraging Large Language Models for Efficient Failure Analysis in Game Development [47.618236610219554]
本稿では,テストの失敗の原因となるコードの変更を自動的に識別する手法を提案する。
このメソッドは、LLM(Large Language Models)を利用して、エラーメッセージと対応するコード変更を関連付ける。
当社のアプローチは新たに作成したデータセットで71%の精度に達しています。
論文 参考訳（メタデータ） (2024-06-11T09:21:50Z) - Code Review Automation: Strengths and Weaknesses of the State of the Art [14.313783664862923]
3つのコードレビュー自動化技術は、この論文で説明した2つのタスクで成功するか失敗する傾向があります。
この研究は質的な焦点が強く、正確な予測と間違った予測の分析に105時間のマニュアルインスペクションが費やされている。
論文 参考訳（メタデータ） (2024-01-10T13:00:18Z) - Improving Code Reviewer Recommendation: Accuracy, Latency, Workload, and
Bystanders [6.538051328482194]
当社は2018年のRevRecV1以降生産されているレコメンデータを構築しています。
私たちは、レビュアーがファイルの以前のオーサシップに基づいて割り当てられていることに気付きました。
レビューに責任を持つ個人を持つことは、レビューにかかる時間を11%削減する。
論文 参考訳（メタデータ） (2023-12-28T17:55:13Z) - Predicting Code Review Completion Time in Modern Code Review [12.696276129130332]
Modern Code Review (MCR)は、オープンソースと商用の両方で共通のプラクティスとして採用されている。
コードレビューは、様々な社会的技術的要因のために完了するのにかなりの遅延を経験することができる。
コードレビューの完了に必要な時間を見積もるためのツールサポートが不足している。
論文 参考訳（メタデータ） (2021-09-30T14:00:56Z) - Deep Just-In-Time Inconsistency Detection Between Comments and Source
Code [51.00904399653609]
本稿では,コード本体の変更によりコメントが矛盾するかどうかを検出することを目的とする。
私たちは、コメントとコードの変更を関連付けるディープラーニングアプローチを開発しています。
より包括的な自動コメント更新システムを構築するために,コメント更新モデルと組み合わせて提案手法の有用性を示す。
論文 参考訳（メタデータ） (2020-10-04T16:49:28Z) - Automating App Review Response Generation [67.58267006314415]
本稿では,レビューと回答の知識関係を学習することで,レビュー応答を自動的に生成する新しいアプローチRRGenを提案する。
58のアプリと309,246のレビュー-レスポンスペアの実験では、RRGenはBLEU-4の点で少なくとも67.4%のベースラインを上回っている。
論文 参考訳（メタデータ） (2020-02-10T05:23:38Z)
関連論文リストは本サイト内にある論文のタイトル・アブストラクトから自動的に作成しています。
指定された論文の情報です。
本サイトの運営者は本サイト（すべての情報・翻訳含む）の品質を保証せず、本サイト（すべての情報・翻訳含む）を使用して発生したあらゆる結果について一切の責任を負いません。