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

コードレビューを通じて行われる
コーディングスタイル修正の分析
上田裕己１，伊原彰紀２，石尾隆１，松本健一１
１奈良先端科学技術大学院大学
２和歌山大学
第25回ソフトウェア工学の基礎ワークショップ FOSE2018

発表のあらまし
• 背景:コードレビュープロセスとスタイル修正
• 分析: レビューでのスタイル修正の調査
RQ1: 変更の分布・内容
RQ2: ツールによる修正効率
• 自動修正に向けた修正事例の収集
2

背景：
コードレビューのプロセス
開発者レビューア
3
投稿プロジェクト
- i=key
+ i=dic[“key”]
パッチ

背景：
4
もう少しよくなりそう
です
検証・修正提案
- i=key
+ i=dic[“key”]
パッチ

背景：
5
OK!
適用
- i=key
+ i=dic[“key”]
- i=key
+ i=dic.get(“key”)
パッチパッチ

問題：レビューア一人あたりが
週に６時間を消費する
6
適用
- i=key
+ i=dic[“key”]
- i=key
レビューア一人あたりが週に６時間を消費する
パッチパッチ

最終目標：コスト削減のため
レビュー投稿前に修正
7
開発者レビューア投稿修正修正ツール
- i=key
+ i=dic[“key”]
- i=key

動作に影響しない(スタイル等)修正が
コードレビューで重要
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
スタイル修正の
内容理解
スタイル修正事例
の収集
自動スタイル修正
RQ1, 2
最終目標
追加分析

分析アプローチ：
レビューを通した修正内容の理解
10
適用
- i=key
+ i=dic[“key”]
- i=key
RQ1：スタイルの問題はどの程度検出されるか？
RQ2：静的解析ツールを用いることでスタイルの
問題をコードレビュー投稿前に検出可能か？

分析対象：
レビューを通したパッチ修正差分
11
適用
投稿直後と適用時
のパッチペア差分
- i=key
+ i=dic[“key”]
- i=key
- i=dic[“key”]

スタイル変更分類手法
パッチペア(変更内容)の差分から
変更チャンクを分類
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
スタイル変更？
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
プロジェクト OpenStack
開発言語 Python3
期間 2011-2013
# パッチ数 173,749 件
# 対象パッチ数 382 件
# 対象チャンク数 981 件
静的解析ツール Pylint

RQ1：スタイルの問題はどの程度検出
されるか？
15
変更チャンク981件
機能に影響のある修正
52.0% (510件)
スタイル修正
48.0% (471件)

されるか？
16
52.0% (510件)
スタイル修正
48.0% (471件)
コードの改善が重要という
開発者の感覚は正しかった

されるか？
17
文
字
列
の
修
正
動作に影響しない
インデント
（タブ）
164件
空
白
削
除
その他
241件
52.0% (510件)
スタイル修正
48.0% (471件)
使
用
変
数
変
更

されるか？
18
52.0% (510件)
スタイル修正
48.0% (471件)
約半数がスタイル修正
一部は現状の自動修正が困難
文
字
列
の
修
正
動作に影響しない
インデント
（タブ）
164件
空
白
削
除
その他
241件
使
用
変
数
変
更

スタイル修正の内容を調査
19
修正 981件
スタイル修正 471件
• RQ1：スタイルの問題はどの程度検出されるか？
約半数がスタイル修正（一部は自動修正が困難）

20
検出可能な
スタイル修正
???件
• RQ2：静的解析ツールを用いることでスタイルの問題
をコードレビュー投稿前に検出可能か？

スタイル修正の現状：
ツールによって一部自動検出可能
21
FOO=0
print(“var = ” + FOO)
foo␣=␣0
print(“var =”, foo)
自動検出可能な例：
• 命名規則違反
• 空白の過不足
• 文字列のフォーマット
Pythonではpylint, pep8などが既存のルール違反を検出

スタイル修正の現状：
開発者の経験が必要な修正が存在
22
- i=dic[“key”] + i=dic.get(“key”)
修正目的：存在しない辞書アクセスに対して
エラーではなくNoneを返す
- assertEqual(x,None)
修正目的：可読性の向上とカスタムクラスへの対応
+ assertIsNone(x)

23
修正 981件
検出可能な
スタイル修正
132件

24
修正 981件
検出可能な
スタイル修正
132件
開発者にツール利用を促すことで
1３%は検証コストを削減できる

頻繁に出現した
検出可能なスタイル修正
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
スタイル修正の
内容理解
スタイル修正事例
の収集
自動スタイル修正
RQ1, 2
最終目標
追加分析

編集距離を利用した
スタイル修正事例の収集
• 仮定：編集距離が短いものはスタイル修正
27
編集距離が１以下の修正のうち89％は
スタイル修正
編集距離=1 編集距離=2
-
if␣(i␣==␣0){
+
{
- if (i == 0){
+ if (j == 0){
- if (i == 0){
+ if (j == 1){
編集距離=0 (空白，改行のみ)

変更トークンごとの編集距離
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
編集距離が３以下の変更を
スタイル修正として収集可能
精度 0.89
再現率 0.62
F値 0.73
• 文字列リテラルの変更
• 編集距離 ≦ 1
精度 0.47
再現率 0.28
F値 0.35
精度 0.71
再現率 0.75
F値 0.73
• 編集距離 ≦ 3

スタイル修正を活用した今後の展望
• スタイル修正の修正パターンの検出
30
- self.assertEquals(x, y)
+ self.assertEqual(x, y)
• 自動スタイル修正
開発者レビューア投稿修正修正ツール
例：Pythonのバージョン更新による仕様変化

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

Recommandé

Recommandé

Contenu connexe

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

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

Plus de 奈良先端大情報科学研究科

Plus de 奈良先端大情報科学研究科 (20)