Fugu-MT 論文翻訳(概要): Beyond the Tip of the Iceberg: Understanding SATD in Dockerfiles through the Lens of Co-evolution

論文の概要: Beyond the Tip of the Iceberg: Understanding SATD in Dockerfiles through the Lens of Co-evolution

arxiv url: http://arxiv.org/abs/2605.21238v1
Date: Wed, 20 May 2026 14:26:56 GMT
ステータス: 翻訳完了
システム内更新日: 2026-05-21 19:19:56.723076
Title: Beyond the Tip of the Iceberg: Understanding SATD in Dockerfiles through the Lens of Co-evolution
Title（参考訳）: Icebergのチップを超えて - 共進化のレンズによるDockerfileでのSATD理解
Authors: Wei Minn, Yan Naing Tun, Biniam Fesseha Demissie, Rui'ang Hu, Jiakun Liu, Mariano Ceccato, Lwin Khin Shar, David Lo,
Abstract要約: 我々は,Dockerfileの自己許容技術的負債(SATD)と関連するソースコードについて検討する。受け入れイベントの約27%と返済イベントの40%が、Dockerfile以外のアーティファクトに結合されていることが分かりました。
参考スコア（独自算出の注目度）: 10.059038321113546
License: http://creativecommons.org/licenses/by/4.0/
Abstract: Dockerfiles enable the creation of portable container-based execution environments for the application code, and have become an important part of the modern software development process. As Dockerfiles are a form of Infrastructure-as-Code (IaC), they can include temporary workarounds and other suboptimal implementations, leading to the accrual of technical debt that affects their reliability, security, and maintainability in the future. Prior work characterized self-admitted technical debt (SATD) in Dockerfile comments and the surrounding file chunks. This single-file view is incomplete since source code evolution involves changes across different types of software artifacts such as production, test, build, and other configuration files. Thus, we address this gap by studying SATD events in Dockerfiles alongside the related source code. We find that approximately 27% of admission events and 40% of repayment events are coupled to non-Dockerfile artifacts, and coupling sources are subtype-specific. We also observed that coupled SATD in general are repaid significantly faster overall (p = 0.0201), while coupled SATD regarding missing functionalities persists longer than its isolated counterparts; Lastly, we conducted open and axial coding of coupled SATD events, and we observe that external dependency issues, more particularly regarding unreleased upstream packages and bug fixes, are the most common cause of admission triggers in the source code; we also observe that architectural refactoring is the most common prerequisite for the repayment of SATD in Dockerfiles. These findings indicate that both practitioners (e.g. developers and project managers) and SATD researchers should integrate the source code-side co-evolution, rather than the single-file view, as the primary unit of analysis.
Abstract（参考訳）: Dockerfilesは、アプリケーションコードのためのポータブルなコンテナベースの実行環境の作成を可能にする。 Dockerfileはインフラストラクチャ・アズ・コード(Infrastructure-as-Code, IaC)の形式であるため、一時的な回避策やその他の準最適実装を含めることができる。以前の作業では、Dockerfileコメントと周辺のファイルチャンクに、自己許可型技術的負債(SATD)が特徴的だった。ソースコードの進化には、プロダクション、テスト、ビルド、その他の構成ファイルなど、さまざまな種類のソフトウェアアーチファクトの変更が含まれるため、この単一ファイルビューは不完全である。したがって、Dockerfile内のSATDイベントを関連するソースコードと一緒に研究することで、このギャップに対処する。受け入れイベントの約27%と返済イベントの40%がDockerfile以外のアーティファクトに結合されており、結合ソースはサブタイプ固有のものである。最後に、結合SATDイベントのオープンかつアキシャルなコーディングを行い、特にアップストリームパッケージやバグ修正に関する外部依存性の問題が、ソースコード内で最も一般的なインプットトリガーであることを示した。また、アーキテクチャリファクタリングがDockerfileにおけるSATDの返済の最も一般的な前提条件であることも観察した。これらの結果は、実践者(例えば開発者とプロジェクトマネージャ)とSATD研究者の両方が、単一ファイルビューではなくソースコード側の共進化を分析の主単位として統合すべきであることを示唆している。

関連論文リスト

Effective Strategies for Asynchronous Software Engineering Agents [52.76455094324273]
本稿では,集中型タスクデリゲート,非同期実行,独立したワークスペースという,3つのSWEプリミティブに根ざした構造化マルチエージェント協調パラダイムを導入する。 CAIDは,紙再生タスク(PaperBench)では26.7%,Pythonライブラリ開発タスクでは14.3%,単一エージェントベースラインでは26.7%の精度向上を実現している。
論文参考訳（メタデータ） (2026-03-23T02:26:35Z)
It's Not Just Timestamps: A Study on Docker Reproducibility [0.3553493344868413]
Dockerの測定パイプラインを構築して,Dockerfileを含む2,000のGitHubリポジトリのサンプルに適用します。構築可能なイメージは56%に過ぎず、2.7%はインフラストラクチャの設定なしでビット単位で再現可能である。これらのパターンから具体的なDockerfileガイドラインを導き、再現可能なコンテナに対する将来のlinterとContinuous Integration(CI)チェックを通知する方法について説明します。
論文参考訳（メタデータ） (2026-02-03T00:26:53Z)
Docker Does Not Guarantee Reproducibility [8.363502352389188]
Dockerのようなコンテナ技術は、ソフトウェア環境をイメージとして知られる共有可能なスナップショットにカプセル化することで、この問題に対処する。 Dockerは理論的に可能なツールとして文献にしばしば引用されているが、その保証と実用上の制限の程度は未調査のままである。まず、Dockerが文学に関する科学的談話にどのように組み込まれているかを調べるために、系統的なレビューを実施します。次に、GitHubから収集された5298のDockerfileに関する大規模な実証的研究を行った。
論文参考訳（メタデータ） (2026-01-19T08:16:43Z)
NL2Repo-Bench: Towards Long-Horizon Repository Generation Evaluation of Coding Agents [79.29376673236142]
既存のベンチマークは、完全なソフトウェアシステムを構築するのに必要な長期的能力の厳格な評価に失敗する。符号化エージェントの長期リポジトリ生成能力を評価するために設計されたベンチマークであるNL2Repo Benchを提案する。
論文参考訳（メタデータ） (2025-12-14T15:12:13Z)
Refactoring for Dockerfile Quality: A Dive into Developer Practices and Automation Potential [0.0]
本稿では,358のオープンソースプロジェクトの600fileを使用したDockerfileの自動化の有用性と実用性について検討する。提案手法では,画像サイズが平均32%減少し,ビルド期間が6%減少し,77%,91%の症例で理解性と保守性が向上した。
論文参考訳（メタデータ） (2025-01-23T23:10:47Z)
Codev-Bench: How Do LLMs Understand Developer-Centric Code Completion? [60.84912551069379]
Code-Development Benchmark (Codev-Bench)は、細粒度で現実世界、リポジトリレベル、開発者中心の評価フレームワークです。 Codev-Agentは、リポジトリのクローリングを自動化し、実行環境を構築し、既存のユニットテストから動的呼び出しチェーンを抽出し、データ漏洩を避けるために新しいテストサンプルを生成するエージェントベースのシステムである。
論文参考訳（メタデータ） (2024-10-02T09:11:10Z)
Dockerfile Flakiness: Characterization and Repair [6.518508607788089]
Dockerfileのフレキネスに関する最初の包括的な研究で、Docker化された8,132のプロジェクトの9ヶ月にわたる分析を特徴としている。本稿では,依存性エラーやサーバ接続の問題など,一般的なフラキネスの原因を分類する分類法を提案する。静的および動的解析,類似性検索,および大規模言語モデルを用いた反復的フィードバックループを組み合わせた新しい修復フレームワークであるFLAKIDOCKを紹介する。
論文参考訳（メタデータ） (2024-08-09T23:17:56Z)
On the Security Blind Spots of Software Composition Analysis [46.1389163921338]
Mavenリポジトリで脆弱性のあるクローンを検出するための新しいアプローチを提案する。 Maven Centralから53万以上の潜在的な脆弱性のあるクローンを検索します。検出された727個の脆弱なクローンを検出し、それぞれに検証可能な脆弱性証明プロジェクトを合成する。
論文参考訳（メタデータ） (2023-06-08T20:14:46Z)

関連論文リストは本サイト内にある論文のタイトル・アブストラクトから自動的に作成しています。

指定された論文の情報です。
本サイトの運営者は本サイト（すべての情報・翻訳含む）の品質を保証せず、本サイト（すべての情報・翻訳含む）を使用して発生したあらゆる結果について一切の責任を負いません。