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.
ソースコードの品質向上    のための 効果的で効率的な  コードレビュー 日本工学院八王子専門学校    大圖 衛玄
自己紹介                         1992年~1997年                           某ゲーム会社                           プログラマ                 ...
アジェンダコードレビューの必要性と問題点メトリクス計測と関連ツールの紹介本校の取り組みまとめ、質疑応答
コードレビューしていますか?
コードレビューが できない理由
時間がない
ソースコード量  パネェし
気力も残ってないし
うちの会社では無理です(笑)
(笑)ではありません
よくある怖い話
新人に仕事を丸投げ
コードの酷さに 怒り爆発
納期直前に絶望
神に祈る
神様どうかバグらないでください神様どうか止まらないでくださいもう二度と悪いコードは書きません毎日、早寝、早起きします毎日、日記も書きますゲームは1日1時間南無妙法蓮華経南無阿弥陀仏アーーメン!
新人の責任では ありません
レビューを怠った先輩の責任です
コードレビューの問題点手間、時間、気力の問題大量のコードをどのようにレビューするのか?全ソースコードのレビューは非現実的
ペアプログラミング全ソースのコードレビューが可能!たぶん、会社的に理解してもらえない費用対効果も未知数導入には勇気が必要です
諦めない知恵を使いましょう!
コードレビューの効率化時間がないのなら、レビュー対象を絞り込む明らかに問題がある部分のみレビューする優先度を決定する時間を決め、短時間のレビューを行う
最小限の時間で最大の効果を上げる
コードレビューの対象を絞る プログラム設計全体を俯瞰するレビュー デバック困難なデリケートな部分のレビュー 稚拙なコードに対する教育的なレビュー     対象を絞って、レビューしましょうこれらのレビューは完全に切り分けて行ってください。
本セッションは教育的レビュー が対象です
稚拙なコード とは?
LargeMIT石井教授のスライドを参考にしました。 CEDEC2010の基調講演は感動的でした。
巨大な1枚岩のようなクラス、メソッド。初心者に多い非OOなコードです。
Complexity
一見して何をしているかわからない。迷路のようなコード。
if             if                     for                            if                                 if                ...
Duplicate
Ctrl + C   Ctrl + V   Ctrl + V   Ctrl + V本人の承諾を得ております。
巨大複雑重複コードのレビュー大量のコードから巨大複雑重複を発見するソースファイルを1つずつ開いてチェック?効率的に行う方法が必要
メトリクス計測ツール を活用しましょう!
メトリクス計測していますか?
メトリクス計測やったことない
メトリクス計測は   様々な種類があります
本セッション    では何を計測するのか?
ソフトウェアの 保守性を 計測します
ソフトウェアの保守性とは?可読性理解が容易であるか?変更性変更が容易であるか?試験性デバッグが容易であるか?
巨大複雑重複コード  理解困難  変更困難  試験困難
Villainy
メトリクス計測ツール   活用により
極悪なコードを 自動的に検出可能です
ご紹介するツール  SourceMonitor   コードの大きさ、複雑さを計測  CCFinderX   コードの重複を計測  Cppcheck   静的解析によるエラーチェック検索エンジンにて、各ツール名で検索すれば入手可能です
Free
SourceMonitorコード行数の計測コメント行数の計測ステートメント数の計測循環的複雑度(サイクロマティック数)の計測
ステートメント数コメントや空白行を除く純粋なコード行数{}(ブレース)も含まないセミコロン+制御文の数と考えてよいfor文は3ステートメントでカウントされる
0001:   // 余計な改行はカウントしない0002:   a = b0003:     + c;0004:   // ブレースはカウントしない0005:   m = a;0006:   if (b > m) {0007:        m...
循環的複雑度        Cyclomatic Complexity1976年にThomas J. McCabeが考案制御構造に着目した複雑さのメトリクスコードの複雑さを数値化する分岐が多いコードほど大きな数値となる
m = a;           m=a   if (b > m) {                    b>m      m = b;   }                m=b   if (c > m) {              ...
①循環的複雑度            1                  ②エッジ数 - ノード数 + 2                  2                  ③エッジ数 フローチャートの線の数      3       ...
ほぼ制御文の数+1 になります
複合条件(&&、||)でも増加します
循環的複雑度        Cyclomatic Complexity↓5    単純な構造↓10   良い構造↑30   構造に疑問↑50   テスト、デバッグ困難↑75   変更時に誤修正を生む原因を作る
循環的複雑度 10以下 が望ましい
32を超えると       バグを含んでいる       確率が高くなる          by IBMIBMの調査結果があるそうです。
SourceMonitor             デモ簡単なデモを行いました。
CCFinderX コードクローン(重複したコード)の検出 コピー&ペーストしたコードを顕在化 プログラム全体での重複チェックを行う 現在は、オープンソース化されている更新終了しています。利用してるPythonのバージョンも古いです。注...
CCFinderX             デモ簡単なデモを行いました。
Cppcheck 静的コード解析によるエラーチェック 未初期化変数の警告 バッファオーバーラン、メモリリークの検出 STLの正しい使用法の警告現在、活発にアップデートをしています。商用のものが使用できない方におすすめです。
Cppcheck                 デモ簡単なデモを行いました。
メトリクス計測を始めましょう 明らかに悪い部分を自動的に発見可能 客観的に数値化される リファクタリングを行う明確な基準ができる ソースコードの品質を一定以上に保てる主観的評価では、人を納得させるのは難しいです。特にベテランは・・・
計測できないものは   コントロールできない   Lord Kelvinメトリクス計測関係の本に引用されることが多い言葉です。
品質管理計測必須
チーム制作の授業の概要 前期、後期の半年毎のチーム制作 1チーム5~8名、20チーム前後 学年を超えたチーム編成 アジャイル開発(XPとScrumをアレンジ)本校の取り組みを紹介しました。
クソース問題アジャイル開発は成功しましたが、ソースコードの質はひどい状態でした。
クソース [kusource]   理解不能で変更困難なプログラムコード。   巨大かつ複雑で、重複しているケースも多   い。変更するたびにバグが発生し、バグが   収束することはない。   地方によっては、 uncodeと呼ばれる。ネタです...
クソース問題SourceMonitorの計測を義務化していたしかし、完成優先でクソースを量産動作させるので精一杯な学生も多いが…コーディング規約を決めることにした!
7つのコーディング規約             お尻は掻いても             クソース書くな実際の授業で利用したスライドです。
複雑度 10 まで
1メソッド    10ステートメントまで
1クラス   100ステートメントまで
ネスト  2段階まで
複合条件 2つ まで
フィールド 4つ まで
ソースコードを   愛  せよ
tweet!      ソースコードを         愛        せよ恥ずかしがらずに、つぶやいてみましょう。
クソース問題コーディング規約のチェックをどうするか?SourceMonitorで全チームチェック?20チーム以上を毎回計測するのは非効率計測結果を一覧できる仕組みを作ろう!
KuSourceMonitorの作成SourceMonitorのXML出力機能を活用XMLの計測結果を独自に集計しHTML化違反数、違反率の集計表を作成違反しているメソッドのソースコードを抽出
バッチ処理用XML SourceMonitor    計測結果XML                 KuSourceMonitorコマンドラインによるバッチ処理で行います                  集計結果HTML
KuSourceMonitor           デモ簡単なデモと、使用前、使用後のプロジェクト結果を比較しました。
クソースの顕在化に成功集計結果を共有サーバーにアップ全学生が閲覧可能となるいじめにならないか? という懸念もあった顕在化後、リファクタリングが活発になる
顕在化による効果 クソースがさらされるのは誰でも嫌! 自尊心、羞恥心に訴える できる学生ほど、プライドが高い チーム間の競争もあった数値化されると燃える!という学生もいました。
他人に見られていることを   意識すればコードは美しくなる   Moriharu Ohzuネタです。申し訳ありません。
問題を顕在化   するのが品質管理の基本です
今後の取り組み  商用メトリクス計測ツールの導入  もっと多くのメトリクス計測が可能  クラス設計のメトリクス計測をしたい!  高精度の静的解析によるエラーチェックも!本校では、Klocworkの導入に向けて、準備中です。
クラス設計のメトリクス計測 継承の深さ、子クラスの数の計測 フィールド数、凝集性の計測 他クラスとの結合度の計測 明らかに設計が悪いクラスを検出できる商用ツールは強力です。Javaの世界にはフリーでも良いツールが存在します。
コーディング規約の調整               理想       標準    妥協  複雑度           5        10   20  ネスト           2        3     4  メソッド長        ...
計測によるレビューの注意点 クソースは減りますが・・・ 静的解析にも限界はあります・・・ 油断してはいけません 新人には丁寧なレビューをしてあげましょう!短時間で良いので、レビューしてあげてください。
理想的なコード普通のコード クソース
理想的なコード               普通のコード計測によるレビューでは、クソースがなくなるだけです。
計測によるレビューの注意点 明らかに悪い部分を検出するのが目的 理想を目指すなら、人力レビューが必要 人力レビューの効率化にも可読性が必須 クリーンなコードに対して、人力レビューする理想を目指すなら、人力レビューが必要。しかしクソースは...
計測によるレビュー       により    品質の底上げが可能クソースがなくなるだけでも効果はあります。
SourceMonitor            から      はじめてみましょう!コードを計測する習慣をつけましょう。SourceMonitorは手軽なツールです。
予算があれば        Klocwork         導入しましょう!    丸紅情報システムズ株式会社展示ブースにて       絶賛デモンストレーション中!CEDEC2011の展示ブースにて、デモが行われていました。
まとめ まずは、計測するところから始める 計測により、効率のよいレビューが可能 計測結果を分かりやすく顕在化する 顕在化による効果は絶大!顕在化しないと、意識が変わりません。
保守性メトリクスに関しては、Code Qualityの第7章に詳しい説明があります。
質問に関しては、ohzu@hac.neec.ac.jpにお願いします。
ソースコードを         愛        せよソースコードを愛していれば、クソースは書けません。
ソースコードの品質向上のための効果的で効率的なコードレビュー
ソースコードの品質向上のための効果的で効率的なコードレビュー
ソースコードの品質向上のための効果的で効率的なコードレビュー
ソースコードの品質向上のための効果的で効率的なコードレビュー
ソースコードの品質向上のための効果的で効率的なコードレビュー
ソースコードの品質向上のための効果的で効率的なコードレビュー
ソースコードの品質向上のための効果的で効率的なコードレビュー
ソースコードの品質向上のための効果的で効率的なコードレビュー
Upcoming SlideShare
Loading in …5
×

ソースコードの品質向上のための効果的で効率的なコードレビュー

154,151 views

Published on

Published in: Technology

ソースコードの品質向上のための効果的で効率的なコードレビュー

  1. 1. ソースコードの品質向上 のための 効果的で効率的な コードレビュー 日本工学院八王子専門学校 大圖 衛玄
  2. 2. 自己紹介 1992年~1997年 某ゲーム会社 プログラマ SFC,GB,PS1,N64のゲーム開発経験 1998年~現在 日本工学院八王子専門学校 @mozmoz1972 専任講師 プログラミング教育を中心に担当twitterもfacebookも実名です。よかったらフォローしてください。
  3. 3. アジェンダコードレビューの必要性と問題点メトリクス計測と関連ツールの紹介本校の取り組みまとめ、質疑応答
  4. 4. コードレビューしていますか?
  5. 5. コードレビューが できない理由
  6. 6. 時間がない
  7. 7. ソースコード量 パネェし
  8. 8. 気力も残ってないし
  9. 9. うちの会社では無理です(笑)
  10. 10. (笑)ではありません
  11. 11. よくある怖い話
  12. 12. 新人に仕事を丸投げ
  13. 13. コードの酷さに 怒り爆発
  14. 14. 納期直前に絶望
  15. 15. 神に祈る
  16. 16. 神様どうかバグらないでください神様どうか止まらないでくださいもう二度と悪いコードは書きません毎日、早寝、早起きします毎日、日記も書きますゲームは1日1時間南無妙法蓮華経南無阿弥陀仏アーーメン!
  17. 17. 新人の責任では ありません
  18. 18. レビューを怠った先輩の責任です
  19. 19. コードレビューの問題点手間、時間、気力の問題大量のコードをどのようにレビューするのか?全ソースコードのレビューは非現実的
  20. 20. ペアプログラミング全ソースのコードレビューが可能!たぶん、会社的に理解してもらえない費用対効果も未知数導入には勇気が必要です
  21. 21. 諦めない知恵を使いましょう!
  22. 22. コードレビューの効率化時間がないのなら、レビュー対象を絞り込む明らかに問題がある部分のみレビューする優先度を決定する時間を決め、短時間のレビューを行う
  23. 23. 最小限の時間で最大の効果を上げる
  24. 24. コードレビューの対象を絞る プログラム設計全体を俯瞰するレビュー デバック困難なデリケートな部分のレビュー 稚拙なコードに対する教育的なレビュー 対象を絞って、レビューしましょうこれらのレビューは完全に切り分けて行ってください。
  25. 25. 本セッションは教育的レビュー が対象です
  26. 26. 稚拙なコード とは?
  27. 27. LargeMIT石井教授のスライドを参考にしました。 CEDEC2010の基調講演は感動的でした。
  28. 28. 巨大な1枚岩のようなクラス、メソッド。初心者に多い非OOなコードです。
  29. 29. Complexity
  30. 30. 一見して何をしているかわからない。迷路のようなコード。
  31. 31. if if for if if ifネスト地獄です。よく考えずにコードを書くとこうなりますよね。
  32. 32. Duplicate
  33. 33. Ctrl + C Ctrl + V Ctrl + V Ctrl + V本人の承諾を得ております。
  34. 34. 巨大複雑重複コードのレビュー大量のコードから巨大複雑重複を発見するソースファイルを1つずつ開いてチェック?効率的に行う方法が必要
  35. 35. メトリクス計測ツール を活用しましょう!
  36. 36. メトリクス計測していますか?
  37. 37. メトリクス計測やったことない
  38. 38. メトリクス計測は 様々な種類があります
  39. 39. 本セッション では何を計測するのか?
  40. 40. ソフトウェアの 保守性を 計測します
  41. 41. ソフトウェアの保守性とは?可読性理解が容易であるか?変更性変更が容易であるか?試験性デバッグが容易であるか?
  42. 42. 巨大複雑重複コード 理解困難 変更困難 試験困難
  43. 43. Villainy
  44. 44. メトリクス計測ツール 活用により
  45. 45. 極悪なコードを 自動的に検出可能です
  46. 46. ご紹介するツール SourceMonitor コードの大きさ、複雑さを計測 CCFinderX コードの重複を計測 Cppcheck 静的解析によるエラーチェック検索エンジンにて、各ツール名で検索すれば入手可能です
  47. 47. Free
  48. 48. SourceMonitorコード行数の計測コメント行数の計測ステートメント数の計測循環的複雑度(サイクロマティック数)の計測
  49. 49. ステートメント数コメントや空白行を除く純粋なコード行数{}(ブレース)も含まないセミコロン+制御文の数と考えてよいfor文は3ステートメントでカウントされる
  50. 50. 0001: // 余計な改行はカウントしない0002: a = b0003: + c;0004: // ブレースはカウントしない0005: m = a;0006: if (b > m) {0007: m = b;0008: } 4ステートメント
  51. 51. 循環的複雑度 Cyclomatic Complexity1976年にThomas J. McCabeが考案制御構造に着目した複雑さのメトリクスコードの複雑さを数値化する分岐が多いコードほど大きな数値となる
  52. 52. m = a; m=a if (b > m) { b>m m = b; } m=b if (c > m) { c>m m = c; } m=cフローチャートに直して説明します。
  53. 53. ①循環的複雑度 1 ②エッジ数 - ノード数 + 2 2 ③エッジ数 フローチャートの線の数 3 7ノード数 ④ フローチャートの要素数 4 ⑤ 58-7+2= 3 ⑥ 8 6 ⑦
  54. 54. ほぼ制御文の数+1 になります
  55. 55. 複合条件(&&、||)でも増加します
  56. 56. 循環的複雑度 Cyclomatic Complexity↓5 単純な構造↓10 良い構造↑30 構造に疑問↑50 テスト、デバッグ困難↑75 変更時に誤修正を生む原因を作る
  57. 57. 循環的複雑度 10以下 が望ましい
  58. 58. 32を超えると バグを含んでいる 確率が高くなる by IBMIBMの調査結果があるそうです。
  59. 59. SourceMonitor デモ簡単なデモを行いました。
  60. 60. CCFinderX コードクローン(重複したコード)の検出 コピー&ペーストしたコードを顕在化 プログラム全体での重複チェックを行う 現在は、オープンソース化されている更新終了しています。利用してるPythonのバージョンも古いです。注意が必要です。
  61. 61. CCFinderX デモ簡単なデモを行いました。
  62. 62. Cppcheck 静的コード解析によるエラーチェック 未初期化変数の警告 バッファオーバーラン、メモリリークの検出 STLの正しい使用法の警告現在、活発にアップデートをしています。商用のものが使用できない方におすすめです。
  63. 63. Cppcheck デモ簡単なデモを行いました。
  64. 64. メトリクス計測を始めましょう 明らかに悪い部分を自動的に発見可能 客観的に数値化される リファクタリングを行う明確な基準ができる ソースコードの品質を一定以上に保てる主観的評価では、人を納得させるのは難しいです。特にベテランは・・・
  65. 65. 計測できないものは コントロールできない Lord Kelvinメトリクス計測関係の本に引用されることが多い言葉です。
  66. 66. 品質管理計測必須
  67. 67. チーム制作の授業の概要 前期、後期の半年毎のチーム制作 1チーム5~8名、20チーム前後 学年を超えたチーム編成 アジャイル開発(XPとScrumをアレンジ)本校の取り組みを紹介しました。
  68. 68. クソース問題アジャイル開発は成功しましたが、ソースコードの質はひどい状態でした。
  69. 69. クソース [kusource] 理解不能で変更困難なプログラムコード。 巨大かつ複雑で、重複しているケースも多 い。変更するたびにバグが発生し、バグが 収束することはない。 地方によっては、 uncodeと呼ばれる。ネタです、申し訳ありません。uncodeの「un 」はローマ字読みしてください。
  70. 70. クソース問題SourceMonitorの計測を義務化していたしかし、完成優先でクソースを量産動作させるので精一杯な学生も多いが…コーディング規約を決めることにした!
  71. 71. 7つのコーディング規約 お尻は掻いても クソース書くな実際の授業で利用したスライドです。
  72. 72. 複雑度 10 まで
  73. 73. 1メソッド 10ステートメントまで
  74. 74. 1クラス 100ステートメントまで
  75. 75. ネスト 2段階まで
  76. 76. 複合条件 2つ まで
  77. 77. フィールド 4つ まで
  78. 78. ソースコードを 愛 せよ
  79. 79. tweet! ソースコードを 愛 せよ恥ずかしがらずに、つぶやいてみましょう。
  80. 80. クソース問題コーディング規約のチェックをどうするか?SourceMonitorで全チームチェック?20チーム以上を毎回計測するのは非効率計測結果を一覧できる仕組みを作ろう!
  81. 81. KuSourceMonitorの作成SourceMonitorのXML出力機能を活用XMLの計測結果を独自に集計しHTML化違反数、違反率の集計表を作成違反しているメソッドのソースコードを抽出
  82. 82. バッチ処理用XML SourceMonitor 計測結果XML KuSourceMonitorコマンドラインによるバッチ処理で行います 集計結果HTML
  83. 83. KuSourceMonitor デモ簡単なデモと、使用前、使用後のプロジェクト結果を比較しました。
  84. 84. クソースの顕在化に成功集計結果を共有サーバーにアップ全学生が閲覧可能となるいじめにならないか? という懸念もあった顕在化後、リファクタリングが活発になる
  85. 85. 顕在化による効果 クソースがさらされるのは誰でも嫌! 自尊心、羞恥心に訴える できる学生ほど、プライドが高い チーム間の競争もあった数値化されると燃える!という学生もいました。
  86. 86. 他人に見られていることを 意識すればコードは美しくなる Moriharu Ohzuネタです。申し訳ありません。
  87. 87. 問題を顕在化 するのが品質管理の基本です
  88. 88. 今後の取り組み 商用メトリクス計測ツールの導入 もっと多くのメトリクス計測が可能 クラス設計のメトリクス計測をしたい! 高精度の静的解析によるエラーチェックも!本校では、Klocworkの導入に向けて、準備中です。
  89. 89. クラス設計のメトリクス計測 継承の深さ、子クラスの数の計測 フィールド数、凝集性の計測 他クラスとの結合度の計測 明らかに設計が悪いクラスを検出できる商用ツールは強力です。Javaの世界にはフリーでも良いツールが存在します。
  90. 90. コーディング規約の調整 理想 標準 妥協 複雑度 5 10 20 ネスト 2 3 4 メソッド長 10 20 40 クラス長 80 160 240今後の課題です。厳しすぎても、ユルすぎてもダメです。
  91. 91. 計測によるレビューの注意点 クソースは減りますが・・・ 静的解析にも限界はあります・・・ 油断してはいけません 新人には丁寧なレビューをしてあげましょう!短時間で良いので、レビューしてあげてください。
  92. 92. 理想的なコード普通のコード クソース
  93. 93. 理想的なコード 普通のコード計測によるレビューでは、クソースがなくなるだけです。
  94. 94. 計測によるレビューの注意点 明らかに悪い部分を検出するのが目的 理想を目指すなら、人力レビューが必要 人力レビューの効率化にも可読性が必須 クリーンなコードに対して、人力レビューする理想を目指すなら、人力レビューが必要。しかしクソースはレビューする価値がない。
  95. 95. 計測によるレビュー により 品質の底上げが可能クソースがなくなるだけでも効果はあります。
  96. 96. SourceMonitor から はじめてみましょう!コードを計測する習慣をつけましょう。SourceMonitorは手軽なツールです。
  97. 97. 予算があれば Klocwork 導入しましょう! 丸紅情報システムズ株式会社展示ブースにて 絶賛デモンストレーション中!CEDEC2011の展示ブースにて、デモが行われていました。
  98. 98. まとめ まずは、計測するところから始める 計測により、効率のよいレビューが可能 計測結果を分かりやすく顕在化する 顕在化による効果は絶大!顕在化しないと、意識が変わりません。
  99. 99. 保守性メトリクスに関しては、Code Qualityの第7章に詳しい説明があります。
  100. 100. 質問に関しては、ohzu@hac.neec.ac.jpにお願いします。
  101. 101. ソースコードを 愛 せよソースコードを愛していれば、クソースは書けません。

×