Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

コードレビューを通じて行われるコーディングスタイル修正の分析

392 views

Published on

上田 裕己1,伊原 彰紀2,石尾 隆1 ,松本 健一1
1奈良先端科学技術大学院大学
2和歌山大学

Published in: Science
  • Be the first to comment

  • Be the first to like this

コードレビューを通じて行われるコーディングスタイル修正の分析

  1. 1. コードレビューを通じて行われる コーディングスタイル修正の分析 上田 裕己1,伊原 彰紀2,石尾 隆1 ,松本 健一1 1奈良先端科学技術大学院大学 2和歌山大学 第25回 ソフトウェア工学の基礎ワークショップ FOSE2018
  2. 2. 発表のあらまし • 背景:コードレビュープロセスとスタイル修正 • 分析: レビューでのスタイル修正の調査 RQ1: 変更の分布・内容 RQ2: ツールによる修正効率 • 自動修正に向けた修正事例の収集 2
  3. 3. 背景: コードレビューのプロセス 開発者 レビューア 3 投稿 プロジェクト - i=key + i=dic[“key”] パッチ
  4. 4. 背景: コードレビューのプロセス 開発者 レビューア 4 投稿 プロジェクト もう少しよくなりそう です 検証・修正提案 - i=key + i=dic[“key”] パッチ
  5. 5. 背景: コードレビューのプロセス 開発者 レビューア 5 投稿 プロジェクト OK! 適用 - i=key + i=dic[“key”] 検証・修正提案 - i=key + i=dic.get(“key”) パッチ パッチ
  6. 6. 問題: レビューア 一人あたりが 週に6時間を消費する 開発者 レビューア 6 投稿 プロジェクト 適用 - i=key + i=dic[“key”] 検証・修正提案 - i=key + i=dic.get(“key”) レビューア一人あたりが週に6時間を消費する パッチ パッチ 検証・修正提案 検証・修正提案
  7. 7. 最終目標:コスト削減のため レビュー投稿前に修正 7 開発者 レビューア投稿 修正修正ツール - i=key + i=dic[“key”] - i=key + i=dic.get(“key”)
  8. 8. 動作に影響しない(スタイル等)修正が コードレビューで重要 Microsoftが従業員873人にコードレビューの目的をイン タビュー, レビューコメントから分析[1] 8 [1] Alberto Bacchelli and Christian Bird. Expectations, outcomes, and challenges of modern code review. In Proc. ICSE’13, pp. 712–721
  9. 9. 発表内容: 自動スタイル修正に向けて 9 スタイル修正の 内容理解 スタイル修正事例 の収集 自動スタイル修正 RQ1, 2 最終目標 追加分析
  10. 10. 分析アプローチ: レビューを通した修正内容の理解 開発者 レビューア 10 投稿 プロジェクト 適用 検証・修正提案 - i=key + i=dic[“key”] - i=key + i=dic.get(“key”) RQ1:スタイルの問題はどの程度検出されるか? RQ2:静的解析ツールを用いることでスタイルの 問題をコードレビュー投稿前に検出可能か?
  11. 11. 分析対象: レビューを通したパッチ修正差分 開発者 レビューア 11 投稿 プロジェクト 適用 検証・修正提案 投稿直後と適用時 のパッチペア差分 - i=key + i=dic[“key”] - i=key + i=dic.get(“key”) - i=dic[“key”] + i=dic.get(“key”)
  12. 12. スタイル変更分類手法 パッチペア(変更内容)の差分から 変更チャンクを分類 12 - if i␣==␣0: + if i==0: break - elif i == 1: - continue + elif j == 1: + return - if i␣==␣0: + if i==0: - elif i == 1: - continue + elif j == 1: + return パッチペアの差分 1チャンク 1チャンク
  13. 13. スタイル変更分類手法 13 スタイル変更? Yes No Yes No - if i␣==␣0: + if i==0: break - elif i == 1: - continue + elif j == 1: + return - if i␣==␣0: + if i==0: - elif i == 1: - continue + elif j == 1: + return パッチペアの差分 1チャンク 1チャンク パッチペア(変更内容)の差分から 変更チャンクを分類
  14. 14. 対象データセット 14 プロジェクト OpenStack 開発言語 Python3 期間 2011-2013 # パッチ数 173,749 件 # 対象パッチ数 382 件 # 対象チャンク数 981 件 静的解析ツール Pylint
  15. 15. RQ1: スタイルの問題はどの程度検出 されるか? 15 変更チャンク981件 機能に影響のある修正 52.0% (510件) スタイル修正 48.0% (471件)
  16. 16. RQ1: スタイルの問題はどの程度検出 されるか? 16 変更チャンク981件 機能に影響のある修正 52.0% (510件) スタイル修正 48.0% (471件) コードの改善が重要という 開発者の感覚は正しかった
  17. 17. RQ1: スタイルの問題はどの程度検出 されるか? 17 文 字 列 の 修 正 動作に影響しない インデント (タブ) 164件 空 白 削 除 変更チャンク981件 その他 241件 機能に影響のある修正 52.0% (510件) スタイル修正 48.0% (471件) 使 用 変 数 変 更
  18. 18. RQ1: スタイルの問題はどの程度検出 されるか? 18 機能に影響のある修正 52.0% (510件) スタイル修正 48.0% (471件) 変更チャンク981件 約半数がスタイル修正 一部は現状の自動修正が困難 文 字 列 の 修 正 動作に影響しない インデント (タブ) 164件 空 白 削 除 その他 241件 使 用 変 数 変 更
  19. 19. 分析アプローチ: スタイル修正の内容を調査 19 修正 981件 スタイル修正 471件 • RQ1:スタイルの問題はどの程度検出されるか? 約半数がスタイル修正(一部は自動修正が困難)
  20. 20. 分析アプローチ: スタイル修正の内容を調査 20 スタイル修正 471件 検出可能な スタイル修正 ???件 • RQ1:スタイルの問題はどの程度検出されるか? • RQ2:静的解析ツールを用いることでスタイルの問題 をコードレビュー投稿前に検出可能か?
  21. 21. スタイル修正の現状: ツールによって一部自動検出可能 21 FOO=0 print(“var = ” + FOO) foo␣=␣0 print(“var =”, foo) 自動検出可能な例: • 命名規則違反 • 空白の過不足 • 文字列のフォーマット Pythonではpylint, pep8などが既存のルール違反を検出
  22. 22. スタイル修正の現状: 開発者の経験が必要な修正が存在 22 - i=dic[“key”] + i=dic.get(“key”) 修正目的:存在しない辞書アクセスに対して エラーではなくNoneを返す - assertEqual(x,None) 修正目的:可読性の向上とカスタムクラスへの対応 + assertIsNone(x)
  23. 23. 分析アプローチ: スタイル修正の内容を調査 23 • RQ1:スタイルの問題はどの程度検出されるか? • RQ2:静的解析ツールを用いることでスタイルの問題 をコードレビュー投稿前に検出可能か? 修正 981件 スタイル修正 471件 検出可能な スタイル修正 132件
  24. 24. 分析アプローチ: スタイル修正の内容を調査 24 • RQ1:スタイルの問題はどの程度検出されるか? • RQ2:静的解析ツールを用いることでスタイルの問題 をコードレビュー投稿前に検出可能か? 修正 981件 スタイル修正 471件 検出可能な スタイル修正 132件 開発者にツール利用を促すことで 13%は検証コストを削減できる
  25. 25. 頻繁に出現した 検出可能なスタイル修正 25 Missing-docstring (コメントがないクラス,関数) Invalid-name(命名規則違反) Bad-continuation(読みにくいインデント) - FOO = 0 - smallCase = 1 + foo = 0 + small_case = 1 - if foo > 0 and - foo < 1: + if foo > 0 and + ␣␣␣␣foo < 1:
  26. 26. 追加分析: 自動化,学習のための スタイル修正事例収集 26 スタイル修正の 内容理解 スタイル修正事例 の収集 自動スタイル修正 RQ1, 2 最終目標 追加分析
  27. 27. 編集距離を利用した スタイル修正事例の収集 • 仮定:編集距離が短いものはスタイル修正 27 編集距離が1以下の修正のうち89%は スタイル修正 編集距離=1 編集距離=2 - if␣(i␣==␣0){ + { - if (i == 0){ + if (j == 0){ - if (i == 0){ + if (j == 1){ 編集距離=0 (空白,改行のみ)
  28. 28. 変更トークンごとの編集距離 28 print(“String”) if (i == 0){ 文字列リテラル 識別子 数字リテラル 記号 編集距離=1 編集距離=2 if (i == 0){ if (i == 0){ - if␣(i␣==␣0){ + ␣␣if(i==0)n { - if (i == 0){ + if (j == 0){ - if (i == 0){ + if (j == 1){ 変更トークン 編集距離 編集距離=0 (空白,改行のみ)
  29. 29. スタイル修正の収集精度 29 編集距離が3以下の変更を スタイル修正として収集可能 精度 0.89 再現率 0.62 F値 0.73 • 文字列リテラルの変更 • 編集距離 ≦ 1 精度 0.47 再現率 0.28 F値 0.35 精度 0.71 再現率 0.75 F値 0.73 • 編集距離 ≦ 3
  30. 30. スタイル修正を活用した今後の展望 • スタイル修正の修正パターンの検出 30 - self.assertEquals(x, y) + self.assertEqual(x, y) • 自動スタイル修正 開発者 レビューア投稿 修正修正ツール 例:Pythonのバージョン更新による仕様変化
  31. 31. まとめ 31

×