[論文レビュー] Beyond the Code: Mining Self-Admitted Technical Debt in Issue Tracker Systems

Laerte Xavier, Fábio Ferreira+2 more|arXiv (Cornell University)|Mar 20, 2020

Software Engineering Research被引用数 7

ひとこと要約

本論文は、開発者が『技術的負債』などのラベルを用いてイシュートラッキングシステムに技術的負債を明示的に文書化する、問題ベースの自己申告型技術的負債（SATD-I）を導入する。5つのオープンソースプロジェクトにおいて286件のSATD-Iを分析した結果、SATD-Iの29％しかコードコメントに記録されておらず、類似したコードの変更量（code churn）にもかかわらず、閉じるまでにより長い時間がかかっていることが判明。45％のケースで早期リリースを目的に負債が導入され、60％は設計上の欠陥に関連していた。研究結果は、問題ベースのTD追跡・管理を支援するツールの開発を提言する。

ABSTRACT

Self-admitted technical debt (SATD) is a particular case of Technical Debt (TD) where developers explicitly acknowledge their sub-optimal implementation decisions. Previous studies mine SATD by searching for specific TD-related terms in source code comments. By contrast, in this paper we argue that developers can admit technical debt by other means, e.g., by creating issues in tracking systems and labelling them as referring to TD. We refer to this type of SATD as issue-based SATD or just SATD-I. We study a sample of 286 SATD-I instances collected from five open source projects, including Microsoft Visual Studio and GitLab Community Edition. We show that only 29% of the studied SATD-I instances can be tracked to source code comments. We also show that SATD-I issues take more time to be closed, compared to other issues, although they are not more complex in terms of code churn. Besides, in 45% of the studied issues TD was introduced to ship earlier, and in almost 60% it refers to Design flaws. Finally, we report that most developers pay SATD-I to reduce its costs or interests (66%). Our findings suggest that there is space for designing novel tools to support technical debt management, particularly tools that encourage developers to create and label issues containing TD concerns.

研究の動機と目的

• 自己申告型技術的負債（SATD）が、ソースコードのコメント以外の場所、特にイシュートラッキングシステムに文書化されているかどうかを調査すること。
• 現実のソフトウェアプロジェクトにおける問題ベースのSATD（SATD-I）の特徴、原因、動機を理解すること。
• コードコメントに記録されたSATD（SATD-C）とイシューに記録されたSATD（SATD-I）の重複度を調査すること。
• 開発者がSATD-Iを導入・返済する理由を特定し、その負債がプロジェクトの保守に与える影響を評価すること。

提案手法

• 本研究は、『技術的負債』や『負債』などの用語がラベルとして付与されたイシュータスクを特定することで、マイクロソフトのVisual StudioやGitLabを含む5つのオープンソースプロジェクトから、合計286件のSATD-Iを収集した。
• SATD-C（コードベースの自己申告型技術的負債）を同定するため、最先端のツール「SATDDetector」を用いて、同じプロジェクトにおいてSATD-Cを検出・比較した。
• 研究者らが、文献に従い10のTDカテゴリに分類して、SATD-Iのインスタンスを手動で分類した。主な分類対象は、設計上の欠陥やコードの重複などであった。
• SATD-Iの返済に関与した30名の開発者に対してアンケートを実施し、負債の導入および解決の動機を理解した。
• コードの変更量（code churn）を測定することで、SATD-Iと非SATDイシューの複雑さの違いを評価し、閉じるまでの時間の差が、より高い複雑さに起因するものでないことを確認した。
• 定性的および定量的分析を用いて、SATD-IとSATD-Cを比較し、負債の導入および返済の背景要因を分析した。

実験結果

リサーチクエスチョン

• RQ1 RQ1: 本研究対象プロジェクトにおける、コードベースのSATD（SATD-C）とイシューベースのSATD（SATD-I）の重複度はどの程度か？
• RQ2 RQ2: SATD-Iインスタンスで最も頻繁に返済される技術的負債の種類は何か？
• RQ3 RQ3: 開発者はなぜSATD-Iをプロジェクトに導入するのか？
• RQ4 RQ4: 開発者はなぜSATD-Iを返済することを選択するのか？その動機は何か？

主な発見

• 調査対象の286件のSATD-Iのうち、わずか29％しかコードコメントに記録されておらず、自己申告型技術的負債の大部分がコードベース外に存在していることが示された。
• SATD-Iのイシューは、類似したコードの変更量（code churn）を示すにもかかわらず、他のイシューと比べてはるかに長い時間で閉じられている。これは、これらのイシューがより複雑であるのではなく、設計やアーキテクチャ的な要因に起因している可能性を示唆している。
• 45％のケースで、技術的負債は早期のソフトウェアリリースを可能にするために導入された。これは、時間的圧力が負債蓄積の要因であることを示している。
• ほぼ60％のSATD-Iインスタンスで、負債は設計上の欠陥に関連しており、そのうち44％は、コード重複や結合度の低さといったメソッドレベルの設計問題に起因していた。
• SATD-Iを返済する主な動機は、利子コストの削減（44％）と、綺麗で保守性の高いコードを維持する（33％）であり、開発者が長期的な保守負担を強く認識していることが示された。
• 本研究は、開発者が積極的にイシュートラッキングシステムを用いて技術的負債を文書化・管理していることを確認した。これは、問題ベースの追跡がTD管理の有効かつ未活用の手段である可能性を示している。