【ICSE2011勉強会】 Understanding Broadcast Based Peer Review on Open Source Software Projects 担当： 大場 光明（名古屋大学）

Presentation on theme: "【ICSE2011勉強会】 Understanding Broadcast Based Peer Review on Open Source Software Projects 担当： 大場 光明（名古屋大学）"— Presentation transcript:

1 【ICSE2011勉強会】 Understanding Broadcast Based Peer Review on Open Source Software Projects 担当： 大場 光明（名古屋大学）

2 研究の目的・手法 オープンソースソフトウェア開発におけるピアレビュー その裏にあるメカニズムや振る舞いについて調査
ある人がパッチを作り、それがコミュニティ全体に ブロードキャスト（同時通報）され、興味のある関係者たちが レビュー、議論を重ねて採否を決める 無視されたり議論が発散したりしそうなのに、実際には 非常に成功している その裏にあるメカニズムや振る舞いについて調査 Apache HTTP server, Subversion, FreeBSD, Linuxカーネル, KDE の5プロジェクトについて調査 無作為に選んだレビューログ（50～200件）を目で見て分析 各プロジェクトのコア開発者（計9名）に電話・メールで聞き取り Session 19 担当：大塲（名古屋大）

3 レビュアーはコードに挟み込むようにコメントしている
Research Question (1) Q1: レビューされるパッチはどう選ばれる? 開発者は自分の興味のある領域や、過去にコミットしていて 責任のある部分に対するパッチを選んでレビューしている 興味のある領域に対する議論や、過去に参加した議論への 返信を様々な手法で抽出 メールフィルタ、件名→コミットログ→diff の段階的な詳細化、 引用に挟みこんでの返信、自分の発言に対する返信には To: や Cc: に自分が含まれるという点 レビュアーはコードに挟み込むようにコメントしている Figure 1: 余白に分析内容を書き込んだレビューログの例（一部） Session 19 担当：大塲（名古屋大）

4 Research Question (2, 3) Q2: なぜパッチは無視されることがあるのか?
OSSプロジェクトでは開発者に時間がない場合、 レビューの質を落とすより、一部を後回しにすることを選ぶ ⇒ 誰からも興味を持たれなかったパッチは無視される コア開発者に興味を持ってもらえるよう、そのパッチの作者が MLに再送するなど努力しなければならない Q3: どんなレビュアーがどのように議論している? OSS開発において各人に固定の役割はなく、 各々の強みを生かした集団的問題解決が行われる 外部の人も客観性や能力があれば重要な参加者に パッチの持つ問題によって、純粋に技術的な議論と、 プロジェクトの目的や対象範囲に関わる議論に分かれる Session 19 担当：大塲（名古屋大）

5 Research Question (4, 5) Q4: 1つのレビューに多数が関わってきたら?
ささいな話題ほど多くの人が関わってきて議論が発散 いわゆる「自転車置き場の議論」 コア開発者はそのような事態をなるべく避けようと努めている 実際、コミッター以外の意見が過半数のレビューは5%以下 Q5: 大規模なプロジェクトでもスケールする? FreeBSD や KDE では話題別のメーリングリストを設けて 効果的に議論を分散 Linux ではパッチを送るときレビュアー個人のアドレスも加え る手法が広く用いられている 90%のメールに複数の宛先（他のプロジェクトでは9%～27%） Session 19 担当：大塲（名古屋大）

6 Session 19: Software System as City: A Controlled experiment
【SIGMOD/VLDB/ICDE2011勉強会】 Session 19: Software System as City: A Controlled experiment Richard Wettel, Michele Lanza and Romain Robbes 担当: 高井 康勢(名古屋大学)

7 背景 Software Visualization(以下SV) Tool 背景にある問題: 研究の目的:
ソースコードなどを可視化し、プログラム理解を支援す るツール 背景にある問題: 色々なツールがあるが、経験的に有用であると評価さ れているツールがほとんどない 　　　　　SVツールの発展・導入を妨げている 研究の目的: SVツールの評価を行う

8 評価対象SVツール CodeCity: ソースコードを都市として表現 既存ツール(Polymetric Views)の拡張
色分けのしかたを変更 出力(Disharmony Map): 建物: クラス 高さ: メソッド数 基礎の面積: 属性数 色: design problem[18] dataに基づく [18] R. Wettel and M. Lanza. Visually localizing design problems with disharmony maps. In Proceedings of Softvis 2008, pages155–164. ACM Press, 2008.

9 ツールの評価にあたり ツールの比較を行うような実験のための ガイドラインをTR[19]にまとめた ガイドラインに基づき評価実験を行った
プログラム理解の補助に関する実験 EclipseとExcelを用いた方法と比較 正確性と所要時間を比較 クラス間関連・変更による影響範囲・主要クラスの特定 [19] R. Wettel, M. Lanza, and R. Robbes. Empirical validation of CodeCity: A controlled experiment. Tech Report 2010/05,University of Lugano, June 2010.

10 CodeCityは、プログラム理解の支援ツールとして非常に有用である
評価 SVツールを利用することで、プログラム理解の正確性 が24%増加し、所要時間が12%減少 概ねほとんどのタスクで双方ともSVツールが優位 上位N・最大などを探すタスクはEclipse+Excelの方が優位 正確性を必要とするプログラム理解 Eclipse+Excelが優位だと予測された SVツールでもそれほど正確性において引けを取らなかった CodeCityは、プログラム理解の支援ツールとして非常に有用である