f. refactoring

16
F. Refactoring 東東東東東東 東東 東 (1) and 東 東東 (2 & 3)

Upload: mili

Post on 23-Feb-2016

44 views

Category:

Documents


0 download

DESCRIPTION

F. Refactoring. 東工大佐伯研 飯田 諒 (1) and 林 晋平 (2 & 3). Reconciling Manual and Automatic Refactoring Presented by X. Ge , Q. L. DuBose , E. Murphy-Hill ( ノースキャロライナ州大 ). 自動リファクタリングツールがあるにも関わらず実際にはほとんど使用されていない すでに手動でリファクタリングの一部を行っているためにツールを利用することができない → Late Awareness 本論文の貢献 - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: F. Refactoring

F. Refactoring

東工大佐伯研飯田 諒 (1) and 林 晋平 (2 &

3)

Page 2: F. Refactoring

Reconciling Manual and Automatic Refactoring

Presented by X. Ge, Q. L. DuBose, E. Murphy-Hill ( ノースキャロライナ州大 )

• 自動リファクタリングツールがあるにも関わらず実際にはほとんど使用されていない– すでに手動でリファクタリングの一部を行っている

ためにツールを利用することができない→Late Awareness

• 本論文の貢献– 被験者実験を行い、手動のリファクタリングが一般

的で、誤りがちであることを示した– 上記の問題点を解決する自動リファクタリングツー

ル BeneFactor を開発

Page 3: F. Refactoring

手動リファクタリングの実際• 12 人の被験者に実際に手動でリファクタリング

を行わせた結果とアンケート結果を利用

• RQ1: どれくらい手動リファクタリングは正確 ?– 正確でない

• complex refactoring においては 90% が不正解• non-complex refactoring においても 21% が不正解

• RQ2:Late Awareness 問題はどれくらい重要 ?– さまざまな被験者が重要と回答

• 半分以上の被験者が一度手動でリファクタリングを始めれば、 8 割において最後まで手動でリファクタリングを行う

Page 4: F. Refactoring

RQ3: 開発者のリファクタリングの作業の流れは?

• 複数の作業の流れをオートマトンで表現• Rename Field リファクタリングの例

• 得られた操作列を進行中のリファクタリングの検知に利用

7 人はフィールドの宣言の書き換え

7 人はすべての参照を書き換え

4 人は” find and replace” を利用してフィールド名を書き換

Page 5: F. Refactoring

BeneFactor• 2つの機能

– Refactoring Detection• 開発者の操作を観察して、進行中の操作がリファ

クタリングの操作列と一致しているかどうかを検知

– Code Modification• 進行中の操作を元に戻し、自動でリファクタリン

グを適用• リファクタリングでない操作もうまく扱う

• ツールの評価は今後の課題

Page 6: F. Refactoring

開発者がcut 操作をする

メソッドの宣言を加えるとアイコンが出

アイコンを選択することで自動でリファクタリング

使用例:Extract method

Page 7: F. Refactoring

WitchDoctor:手動リファクタリングを進行中に検出 , 完遂

select& cut

insert

もしかして : Extract Method

IDE Support for Real-TimeAuto-Completion of Refactorings

Presented by S. R. Foster, W. G. Griswold, S. Lerner ( カリフォルニア大サンディエゴ校 )

※ "WitchDoctor: IDE Support for Real-Time Auto-Completion of Refactorings",Figs. 2, 3, 4 より引用

Page 8: F. Refactoring

考慮すべき要素• 速度

– 手動リファクタリングの進行中に検出 !• 構文解析不能なコードの考慮

– 書いている途中のコードは構文エラーを含む

• リファクタリング手順の多様性– 手動リファクタリングの手順は人それぞれ

• 拡張性– リファクタリングはいっぱいある

• 信頼できる IDE の再利用– 正しいリファクタリング操作の実装は大変

Page 9: F. Refactoring

提案手法Change

Detection

SpecificationMatching

RefactoringHandling

Insert,Delete,Update

((Insert, Covers), method_call)

((Delete,Covers), code_block) ∧((Insert,Covers), method_call) ∧((Insert,Covers), new_method)

Covers,CoveredBy

AST ノード

• キー入力・マウス操作が起こるたびにプログラム行差分を取得

• 差分片と AST を対応付け• Eclipse を用いて , 構文解析不能なプ

ログラムもそれなりに解析• オフセットに基づく対応付け規則

• Rete アルゴリズムを利用し , 溜め込んだ変更データと仕様をマッチング

• 仕様 : refactoring 検出手法 [Prete'10] に基づく

• 例 : Extract Method 仕様

• 仕様にマッチした変更を巻き戻し• Eclipse のリファクタリングを自動で実行

Page 10: F. Refactoring

評価• 対象 : 3 OSS (Eclipse Compare, Eclipse JFace, Struts)• Extract Method を様々な手順で実行する bot を実行

– 手順をランダムに生成し, 50 ミリ秒ごとに自動打鍵– おちゃめ : しばしばセミコロン ; や閉じブレース } を打ち忘れる

結果 2: 十分速かった結果 1: かなり正確だった

200( 人間のタイピング速度 )

※ "WitchDoctor: IDE Support for Real-Time Auto-Completion of Refactorings",Figs. 6, 7 より引用

Page 11: F. Refactoring

BeneFactor と WitchDoctorどこが違うの ?

• BeneFactor 論文には少し書いてある–「WitchDoctor はコード変更のみに注目し

ているが , BeneFactor はコピペ等の開発者の振る舞いも見ている」

Page 12: F. Refactoring

Use, Disuse, and Misuse of Automated Refactorings

• リファクタリングツールはあまり使われていない [Murphy-Hill, ICSE'09]

• 目的 : 自動リファクタリングツールの利用についてのより深い理解– 開発者 26 人 , 1,268時間の開発データを分析

• 学内外 , 7 人が経験年数 10年以上• うち 9 人にインタビュー

– Use, Disuse, Misuse の観点で分析

Presented by M. Vakilian, N. Chen, S. Negara, B. A. Rajkumar, B. P. Bailey, R. E. Johnson (UIUC)

開発者の観測・アンケートに基づき自動リファクタリングツールの利用のされ方を調査

※ 詳細版が TR として公開されてます http://hdl.handle.net/2142/27730

Page 13: F. Refactoring

CodingSpectator• Eclipse での全リ

ファクタリング操作を記録

[PLATEAU'11@SPLASH][ECOOP'12]

成功した ?失敗した ?

キャンセルした ?

http://codingspectator.cs.illinois.edu/

全コード編集操作を記録する CodingTracker の出力も併用

extract

いつ ?

種類

コード片

QA 使った ?問題なく完了したよ

ウィザードの進行状況

コンフィグレーション

※ "Use, Disuse, and Misuse of Automated Refactorings", Fig. 1 より引用

Page 14: F. Refactoring

Use (使われる)

• Quick Assist (QA) はよく使われている

• 知見– 他の IDE (Intelli○ IDEA, Net○eans, ...) も同様の機能を– 臭いの検出→除去 も同様に手軽に実行されるべき

• 35%のリファクタリングが QA経由

• リネームを除けば65%

※ "Use, Disuse, and Misuse of Automated Refactorings", Fig. 2 より引用

Page 15: F. Refactoring

Disuse ( 使われない )• ニーズに乏しい (Pull up, Pull down)• 存在を知らなかった (Generalize Declared Type など )• 名前が悪い (Extract Class など )• 信用できない• 挙動が予測できない

– 複雑– プレビューが使いづらい

• 設定が煩雑

• 知見– 訓練が必要 , 新しいレビュー手段が必要 , シームレ

スな設定方法 , ...

Page 16: F. Refactoring

Misuse (間違って利用)• 開発者は , 警告やエラーが出ていてもリファクタリ

ングを実行する (警告 : 88%, エラー : 68%)

※ "Use, Disuse, and Misuse of Automated Refactorings", Fig. 5 より引用

1 をローカル変数 i として抽出→ 変数名の重複で振る舞い変化警告が出ても開発者はリファクタリングを強行( 5/6 回)

リファクタリングツール利用における問題の多くはユーザビリティ

• "振る舞いが保存されているか " よりもむしろ " 結果が予測できるか ", " インタラクティブ性 " のほうが大事– 我々は振る舞い保存の監獄から抜け出すべき

- 設定のし直しが面倒,後で直せる , ...