2025年4月12日
今週の活動
- Qualitas Corpusの調査
- http://qualitascorpus.com/
- コードアーティファクトの実証研究に使用するためのソフトウェアシステムのコレクション
- オープンソースのJavaソフトウェアシステムの複数のバージョンが含まれている
- 最終リリースは2013年
- 112個のシステム（プロジェクト）のソースコードが記録されている
- コーパス内の各システムの各バージョンにはメタデータが含まれている
- 3種類のディストリビューションがある
- r: 全てのプロジェクトの最新バージョンのみのソースコード
- e: 10以上のバージョンがあるプロジェクトのソースコード
- f: バージョンごとに管理された全てのプロジェクトのソースコード
- Qualitas Corpusを使用するならば、eディストリビューションを採用するのが良さそう
- ただし、eディストリビューションではコミットごとではなくリリースポイントごとにデータが管理されているため、細かな変更履歴を確認できない
得られた成果
- Qualitas CorpusデータセットとGitHubのパブリックリポジトリという2つのデータソースをどのように組み合わせるか？
- Qualitas Corpusの特性
- 長所
- 研究コミュニティで広く認知された標準データセットであり、他研究との比較が容易
- 事前に選別された多様なJavaプロジェクトが含まれており、データの品質が保証されている
- 環境構築やAPI制限への対応が不要で、分析にすぐ着手できる
- リリースポイントごとの明確な区切りがあり、大規模な変更の分析に適している
- 短所
- リリースごとのスナップショットであるため、細かな変更過程を追跡できない
- データセットの最終更新が2013年であり、現代的な開発プラクティスを反映していない
- コミットメッセージ、プルリクエスト、イシューなどのコンテキスト情報が限られている
- Javaプロジェクトに焦点を当てており、多言語分析ができない
- GitHubのパブリックリポジトリの特性
- 長所
- コミット単位の変更履歴により、細かな変更を追跡できる
- コミットメッセージ、プルリクエスト、イシューなどの多様なコンテキスト情報を利用できる
- 様々なプログラミング言語のプロジェクトを分析できる
- 現代的な開発プラクティスを反映したデータを得られる
- 短所
- API制限があるため、大量のデータ処理に制約がある
- プロジェクトによって開発プラクティスが異なるため、データ品質に差がある
- 研究者の選定基準によって結果が左右される可能性がある
- マイニングと処理に計算リソースが必要
- 検討した組み合わせ戦略
- Qualitas Corpusによる初期検証（マクロ分析）
- 目標
- 複数の異常検出アルゴリズムをリリースバージョン間のメトリクス変化に適用し、保守性低下をどの程度予測できるかを特定する
- リリースバージョン間の大規模な変化において、提案手法がSonarQubeよりも何バージョン早く保守性低下の兆候を検出できるかを評価する
- 活動
- リリースポイントごとにSonarQubeと提案手法を適用
- 大規模な変化や長期的な保守性低下兆候を特定
- 異常検出アルゴリズムの初期評価
- 選定したGitHubリポジトリでの詳細分析（ミクロ分析）
- 目標
- マクロ分析で適用したアルゴリズムをプルリクエストのマージポイントに適用し、より細かい粒度での保守性低下兆候の検出能力を評価
- Java以外の言語（Python、JavaScriptなど）にも手法を適用し、言語を超えた手法の一般化可能性を検証
- 活動
- 選定したリポジトリを対象とする
- プルリクエストのマージポイントでSonarQubeと提案手法を適用
- コミットレベルでの細かな変化に基づく保守性低下兆候の検出能力を評価
- 計画をさらに具体化するために行う作業
- SonarQubeが提供する主要なメトリクスを特定し、時系列分析に適したメトリクスを抽出
- プロジェクトの特性や開発スタイルに依存しないもの
- 論文などで保守性低下の明確な指標として確立されているもの
- 異常検出アルゴリズムのしきい値の決定方法を決める
- プロジェクトの開発スタイルによって精度が変化しやすいメトリクスをどのように扱うかを決める
- 今の考え: 最初の研究段階では精度の高いメトリクスに集中することで、手法の有効性を確実に検証すべき
直面した課題
- コードの臭いをどのように分類し、どのようにそれに対処するかを明確にしたい
- 静的解析ツールではルールセットによって分類されている
- 静的解析ツールの仕組みをユーザー目線から定義する
- リファクタリングフェーズでの道具として静的解析ツールがあるという関係性について考える
- 問題ベースでそれぞれの静的解析ツールが対処できることできないことを明らかにする
- データセットがどのように作られたのかを調べて説明できるようにしておく
- リポジトリを選定する際のプロジェクトのドメインの決定基準と根拠を近いうちに決めたい
- リファクタリングの目的とどのようにリファクタリングをするかを知っておくと役立つ
来週の計画