Understanding Code Smell Detection via Code Review: A Study of the OpenStack Community
アブストラクト
- ソフトウェアの品質に影響を与える可能性のある問題の1つに、コードの臭いがある
- これは、欠陥やメンテンナンスの問題につながる可能性のある不適切なプログラミング手法である
- しかし、コードレビュー中にコードの臭いがどの程度特定されるかについてはほとんど分かっていない
- コードレビューで特定されるコードの臭いの概念と、特定された臭いに対してレビュアーが提案する行動と開発者が実行する行動を調査するために、最もアクティブな2つのOpenStackプロジェクト (Nova, Neutron) を使用して、コードレビューにおけるコードの臭いの実証的研究を実施
- キーワード検索とランダム選択によって取得された19,146件のレビューコメントを手動で確認し、コードの臭いの原因と特定された臭いに対して実行された行動を調べるために、1,190件の臭い関連のレビューを取得
- 分析によって分かったこと
- コードレビューでコードの臭いが特定されることは一般的ではない
- 臭いは通常、コーディング規約違反によって引き起こされる
- レビュアーは通常、開発者が臭いを除去できるようにリファクタリングの推奨を含む建設的なフィードバックを提供する
- 開発者は一般的にそれらの推奨に従い、変更を実行する
- これらの結果が示唆すること
- 開発者はコードの臭いを持ち込まないようにプロジェクトでコーディング規約に厳密に従うべきである
- レビューに基づくコードの臭いの検出は、主にレビューが文脈に依存する、つまりレビュアーはプロジェクトの開発チームの一員であり、コードのコンテキストをより意識しているため、開発者が信頼できるアプローチであると認識している
導入
- コードの臭いは、コードや設計上の問題の症状として識別されており、保守性、コードの可読性、テスト可能性、欠陥の発生しやすさなどのソフトウェア品質に悪影響を及ぼす可能性がある
- 臭いの検出と除去に焦点を当てた研究は数多くあり、臭いの検出には多くの静的解析ツールが使用されている
- しかし、これまでの研究では、プログラムの文脈とドメインが臭いの識別に重要であることが示されている
- 文脈情報が考慮されることはほとんどないため、プログラム解析ツールが臭いを正しく識別することは困難である
- 既存の臭い検出ツールは偽陽性を生成することも知られている
- そのため、手動での臭いの検出は、自動アプローチよりも価値があると考えられる
- コードレビューは、コード内の欠陥やその他の問題を検出することでソフトウェアの品質を検証
- コードが読みやすく、理解しやすく、保守可能であることを確認するためのプロセス
- 臭いを検出する静的解析ツールと比較して、コードレビューは通常、同じプロジェクトに属する開発者によって行われるため、レビュアーは文脈情報を十分に考慮し、コード内のコードの臭いをより適切に特定できる可能性がある
- しかし、コードレビュー中にコードの臭いがどの程度特定されるのかや、コードがレビュー担当者によって臭いであると判断されたときに開発者が何らかの措置を講じるかどうかについては、ほとんど分かっていない
- そこで、コードレビューで特定されるコードの臭いの概念を調査し、レビュー実施後に講じられた措置を追跡することにした
- 最も活発な2つのOpenStackプロジェクトからコードレビューに関する議論をマイニングした
- 次に、コードレビュー中にレビュー担当者がコードの臭いを特定する頻度、コードの臭いが生じた理由、それらの臭いに対してレビュー担当者が推奨する措置、開発者が推奨する措置をどのように進めたかを調べるために、定量的および定性的な分析を実施
関連研究
コードの臭いに関する研究
- コードの臭いが欠陥、メンテナンス、プログラム理解などのソフトウェア品質に与える影響を調査する研究が増えている
- Tufanoらは、200件のOSSプロジェクトのバージョン履歴をマイニングし、コードの臭いがいつ導入されたか、そしてそれらの相互作用の背後にある主な理由を研究した
- その結果、一般的には、メンテナンスと進化の活動の結果として臭いが現れることが判明した
- Palombaらが実施した開発者のコードの臭いに対する認識についての調査では、開発者の経験とシステム知識がコードの臭いの特定に重要な要素であることが分かった
- Taibiらによる研究では、大多数の開発者が常に臭いを有害であると考えていることが明らかになった
- Tahirらは、Stack Exchangeの投稿をマイニングし、コードの臭いとアンチパターンの話題が開発者の間でどのように議論されているかを調査した
- その結果、開発者は特定のリファクタリングソリューションを求めるのではなく、コードの臭いやアンチパターンの一般的な評価を求めるためにオンラインフォーラムを広く使用していることが分かった
ソフトウェア開発におけるコードレビュー
- コードレビューに関する実証的研究により、ソフトウェアの品質に影響を与える潜在的なコードレビュー要因が調査されてきた
- 例えば、McIntoshらは、Qt, VTK, ITKプロジェクトにおけるコードレビューの範囲と参加がソフトウェアの品質に与える影響を調査した
- 彼らは、リリース後の欠陥の発生率を指標として使用し、レビューが不十分なコード (レビューの範囲と参加率が低いなど) はソフトウェアの品質に悪影響を与えることを発見した
- Kemererらによる研究では、レビュー率がソフトウェアの品質に与える影響を調査した
- 彼らは、開発者の能力やその他の重要なプロセス変数を考慮した後でも、個人ソフトウェアプロセスのレビュー率が欠陥除去の有効性に影響を与える重要な要因であることを発見した
- Pascarellaらによる研究では、コードレビューはソースコード内のコードの臭いの重大度を軽減するのに役立ったが、これは主に臭い自体とは関係のない他の変更による副作用であることが分かった
方法
リサーチクエスチョン
- RQ1: コードレビュアーが最も頻繁に特定するコードの臭いは何か？
- RQ2: コードレビュー中に特定されるコードの臭いの一般的な原因は何か？
- RQ3: レビュアーと開発者は、特定されたコードの臭いをどのように処理しているか？
- RQ3.1: 特定された臭いに対処するために、レビュアーはどのような対策を提案しているか？
- RQ3.2: 特定された問題に対処するために開発者はどのような措置を講じるか？
- RQ3.3: レビュアーが提案した行動と開発者が実行した行動の間にはどのような関係があるか？
OpenStackプロジェクトとGerritレビューの流れ
- OpenStackは最大のオープンソースコミュニティの1つ
- 最も活発なOpenStackプロジェクトのうち、NovaとNeutronの2つを対象プロジェクトとして選択
- どちらのプロジェクトもGit上に構築されたWebベースのコードレビュープラットフォームであるGerritを使用している
- Gerritは詳細なコードレビューワークフローを提供
- 開発者がコードを変更し、レビューできるようにコードをGerritサーバーに送信
- 次に、検証ボットが静的アナライザーを使用してコードをチェックし、自動テストを実行
- 次に、レビュアーがコードの正式なレビューを実施し、コメントを提供
- 元の作成者は、レビュアーのコメントに返信し、パッチの新しいリビジョンを作成することで必要な変更を実行できる
- このプロセスは、変更がコードベースにマージされるか、作成者によって放棄されるまで繰り返される
キーワードセットの構築
- 初期キーワードセットの作成
- 一般的な用語を含める (コードの臭い、悪い臭い、悪いパターン、アンチパターン、技術的負債など)
- 具体的なコードの臭いの名前を含める (デッドコードなど)
- Tahirらの研究から抽出した用語リストを含める
- 検索とコーパス (テキスト分析のための文書集合) 構築
- 初期キーワードセットの単語を含むレビューコメントを検索
- 見つかったコメントを処理 (識別子分割ルールを適用、例: isDone => is Done)
- データクリーニングと処理
- ストップワード (一般的な単語)、句読点、数字を削除
- 全ての単語を小文字に変換
- Porterステミングアルゴリズムを適用して各単語の語幹 (ステム) を抽出 (例: running, runs, ran => 全てrunに変換)
- 分析
- 文書 - 用語マトリックス (どの文書にどの単語が何回出現するかを示す表) を作成
- 初期キーワードと高頻度で共起する追加の単語を特定 (同じ文書内での共起確率0.05を基準)
キーワード検索されたレビューコメントから臭い関連のレビューを特定
- 自動キーワード検索
- 構築したキーワードセットを使用したPythonスクリプトを開発
- キーワードを含むレビューコメントを検索 (18,082件のコメントが該当)
- 初期手動フィルタリング
- 2人の研究者が独立して、明らかに無関係なコメントを除外
- 両者が無関係を判断したコメントのみを除外
- この段階で3,666件のコメントに削減
- 詳細な文脈分析
- 残りのコメントに対して、さらに詳細な手動分析を実施
- コードレビューの議論やソースコードなどのテキスト情報を慎重に分析
- 2人の研究者が合意した場合のみ、コードの臭いと関連付け
- 不確かな場合や意見が分かれた場合は第三者を交えて議論
- Cohen's Kappaによる一致率は0.85であり、高い信頼性があった
- この段階で1,235件のコメントに削減
- コンテキスト情報の記録
- それぞれのレビューコメントのコンテキスト情報を外部テキストファイルに記録
- 記録内容
- コード変更のURL (特定のプルリクエストなどのURL、レビューが行われた具体的な変更へのリンク)
- 特定されたコードの臭いの種類
- レビュアーと開発者間の議論
- ソースコードのURL (特定のコミットにおけるファイルのURL、コードの臭いが指摘されたファイルへのリンク)
- 最終的に1,174件のコードの臭い関連のレビューに絞り込んだ (同一議論内の複数コメントは統合)
ランダムに選択されたレビューコメントから臭いに関するレビューを特定
- レビュアーや開発者は、研究で使用したキーワード以外の表現でもコードの臭いを議論している可能性がある
- そのため、キーワードベースのマイニングアプローチを補完する必要がある
- キーワードを含まない残りのレビューコメント (291,229件) から無作為にサンプルを抽出
- 95%の信頼水準と3%の誤差マージンに基づき、1,064件のレビューコメントを選択
- 前述のセクションと同じ手動分析プロセスを適用
- 無作為抽出した1,064件のコメントから、16件のコードの臭い関連のレビューを特定
- キーワード検索で得られた1,174件と合わせて、合計1,190件のコードの臭い関連のレビューを収集
手動分析と分類
- RQ1 (最も頻繁に特定されるコードの臭い) の分析
- RQ2 (コードの臭いの原因) の分析
- テーマ分析手法を採用
- MAXQDA (質的研究用ソフトウェア) を使用してコード化
- 分析プロセス
- コードの臭いの原因に関連するテキスト部分をハイライト
- 原因が記載されていない場合は「cause not provided/unknown」と記録
- 共通パターンを特定してテーマを生成
- データセットに戻り、テーマの妥当性を検証
- 各テーマに名前を付けて定義
- 二人の研究者が実施し、意見の相違がある場合は三人目が介入
- RQ3 (対応方法) の分析
- RQ3.1 (レビュアーの提案する対策)
- レビュアーの推奨行動を3つのカテゴリに分類
- 修正 (Fix): コードの臭いをリファクタリングする具体的な推奨
- 捕捉 (Capture): コードの臭いを検出するが具体的なリファクタリング推奨なし
- 無視 (Ignore): 特定された臭いを無視する推奨
- RQ3.2 (開発者の対応)
- 開発者の対応を3段階で調査
- 議論におけるレビュアーへの開発者の返答を確認
- レビュー前のソースコードファイルとレビュー後の変更を調査
- 開発者が返答もコード修正もしない場合、対応するコード変更のステータスを確認
- コードの臭いが解決されたと判断する3つのケース
- 開発者が議論の中でリファクタリングを行うことを明示的に認めた
- ソースコードファイルに変更が加えられた
- 対応するコード変更が破棄された
- RQ3.3 (レビュアーの推奨と開発者の対応の関係)
- 関係性を3つのカテゴリに分類
- 開発者がレビュアーの推奨に同意
- 開発者がレビュアーの推奨に不同意
- 開発者がレビュアーのコメントに無応答
- これらは最終的に2つのアクションに集約
- 臭いを修正 (リファクタリングを実施)
- 変更を無視 (臭いに関してソースコードに変更なし)
結果
- RQ1: コードレビュアーが最も頻繁に特定するコードの臭いはどれか？
- コードレビューではコードの臭いが一般的に特定されていないことが分かった
- 特定されたコードの臭いのうち、重複コードが圧倒的に多かった
- 不適切な命名やデッドコードも頻繁に特定された
- RQ2: コードレビュー中に特定されるコードの臭いの一般的な原因は何か？
- コーディング規約違反
- コーディング規約 (命名規則など) の特定の違反が問題の原因となった
- 既存のコードに対する不慣れさ
- 開発者が既存のコードの機能や構造に不慣れなために、コードの臭いを生じさせた
- 開発者の意図しないミス
- 開発者が問題解決忘れたり、誤って問題を引き起こしたりする
- 不適切な設計
- コードの臭いはコードの不適切な設計に関連していることが判明した
- コード分析ツールによる検出
- レビュアーは、コード分析ツールによってコードの臭いが検出されたことを指摘する
- レビューの大部分 (70%) では、特定されたコードの臭いについて何の説明も提供されていなかった
- ほとんどの場合は、レビュアーは単に問題を指摘しただけで、決定の理由をそれ以上説明していなかった
- 23%のレビューでは、コーディング規約違反がコードの臭いの主な原因であると指摘されている
- RQ3: レビュアーと開発者は、特定されたコードの臭いをどのように処理するか？
- RQ3.1: 特定されたコードの臭いに対処するために、レビュアーはどのような対策を提案するか？
- レビューの大部分 (73%) で、レビュアーは特定されたコードの臭いを解決するための修正を推奨した
- これらの修正のうち35%では、開発者がコードの臭いを適切にリファクタリングできるようにサンプルコードスニペットが提供された
- レビューの23%では、レビュアーはコードの臭いの存在を指摘しただけで、リファクタリングの提案は行っていない
- RQ3.2: 特定された問題に対処するために開発者はどのような措置を講じるか？
- レビューで特定されたコードの臭いのうち、大部分 (86%) はレビュー後に開発者によってリファクタリングされた
- RQ3.3: レビュアーが提案した行動と開発者が実行した行動の間にはどのような関係があるか？
- 得られたレビューのうち65%で、開発者はレビュアーの提案に同意し、レビュアーが提案したのと全く同じ行動を実行した
引用情報
- 著者: Xiaofeng Han, Amjed Tahir, Peng Liang, Steve Counsell, Yajing Luo
- タイトル: Understanding Code Smell Detection via Code Review: A Study of the OpenStack Community
- 雑誌 / 会議名: 2021 IEEE/ACM 29th International Conference on Program Comprehension (ICPC)
- ページ: pp. 323-334
- 出版日: May 2021
- DOI: https://doi.org/10.1109/ICPC52881.2021.00038