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

ソースコードの品質向上のための効果的で効率的なコードレビュー日本工学院八王子専門学校大圖衛玄

自己紹介 1992年～1997年某ゲーム会社プログラマ SFC,GB,PS1,N64のゲーム開発経験 1998年～現在日本工学院八王子専門学校 @mozmoz1972 専任講師プログラミング教育を中心に担当twitterもfacebookも実名です。よかったらフォローしてください。

アジェンダコードレビューの必要性と問題点メトリクス計測と関連ツールの紹介本校の取り組みまとめ、質疑応答

コードレビューしていますか？

コードレビューができない理由

時間がない

ソースコード量パネェし

気力も残ってないし

うちの会社では無理です（笑）

（笑）ではありません

よくある怖い話

新人に仕事を丸投げ

コードの酷さに怒り爆発

納期直前に絶望

神に祈る

神様どうかバグらないでください神様どうか止まらないでくださいもう二度と悪いコードは書きません毎日、早寝、早起きします毎日、日記も書きますゲームは１日１時間南無妙法蓮華経南無阿弥陀仏アーーメン！

新人の責任ではありません

レビューを怠った先輩の責任です

コードレビューの問題点手間、時間、気力の問題大量のコードをどのようにレビューするのか？全ソースコードのレビューは非現実的

ペアプログラミング全ソースのコードレビューが可能！たぶん、会社的に理解してもらえない費用対効果も未知数導入には勇気が必要です

諦めない知恵を使いましょう！

コードレビューの効率化時間がないのなら、レビュー対象を絞り込む明らかに問題がある部分のみレビューする優先度を決定する時間を決め、短時間のレビューを行う

最小限の時間で最大の効果を上げる

コードレビューの対象を絞る プログラム設計全体を俯瞰するレビュー デバック困難なデリケートな部分のレビュー 稚拙なコードに対する教育的なレビュー対象を絞って、レビューしましょうこれらのレビューは完全に切り分けて行ってください。

本セッションは教育的レビューが対象です

稚拙なコードとは？

LargeMIT石井教授のスライドを参考にしました。 CEDEC2010の基調講演は感動的でした。

巨大な１枚岩のようなクラス、メソッド。初心者に多い非OOなコードです。

Complexity

一見して何をしているかわからない。迷路のようなコード。

if if for if if ifネスト地獄です。よく考えずにコードを書くとこうなりますよね。

Duplicate

Ctrl + C Ctrl + V Ctrl + V Ctrl + V本人の承諾を得ております。

巨大複雑重複コードのレビュー大量のコードから巨大複雑重複を発見するソースファイルを１つずつ開いてチェック？効率的に行う方法が必要

メトリクス計測ツールを活用しましょう！

メトリクス計測していますか？

メトリクス計測やったことない

メトリクス計測は様々な種類があります

本セッションでは何を計測するのか？

ソフトウェアの保守性を計測します

ソフトウェアの保守性とは？可読性理解が容易であるか？変更性変更が容易であるか？試験性デバッグが容易であるか？

巨大複雑重複コード理解困難変更困難試験困難

Villainy

メトリクス計測ツール活用により

極悪なコードを自動的に検出可能です

ご紹介するツール SourceMonitor コードの大きさ、複雑さを計測 CCFinderX コードの重複を計測 Cppcheck 静的解析によるエラーチェック検索エンジンにて、各ツール名で検索すれば入手可能です

SourceMonitorコード行数の計測コメント行数の計測ステートメント数の計測循環的複雑度（サイクロマティック数）の計測

ステートメント数コメントや空白行を除く純粋なコード行数｛｝（ブレース）も含まないセミコロン＋制御文の数と考えてよいfor文は３ステートメントでカウントされる

0001: // 余計な改行はカウントしない0002: a = b0003: + c;0004: // ブレースはカウントしない0005: m = a;0006: if (b > m) {0007: m = b;0008: } ４ステートメント

循環的複雑度 Cyclomatic Complexity1976年にThomas J. McCabeが考案制御構造に着目した複雑さのメトリクスコードの複雑さを数値化する分岐が多いコードほど大きな数値となる

m = a; m=a if (b > m) { b>m m = b; } m=b if (c > m) { c>m m = c; } m=cフローチャートに直して説明します。

①循環的複雑度 1 ②エッジ数－ノード数＋２ 2 ③エッジ数フローチャートの線の数 3 7ノード数 ④ フローチャートの要素数 4 ⑤ 5８－７＋２＝３ ⑥ 8 6 ⑦

ほぼ制御文の数＋１になります

複合条件（＆＆、｜｜）でも増加します

循環的複雑度 Cyclomatic Complexity↓５単純な構造↓１０良い構造↑３０構造に疑問↑５０テスト、デバッグ困難↑７５変更時に誤修正を生む原因を作る

循環的複雑度 10以下が望ましい

32を超えるとバグを含んでいる確率が高くなる by IBMIBMの調査結果があるそうです。

SourceMonitor デモ簡単なデモを行いました。

CCFinderX コードクローン（重複したコード）の検出 コピー＆ペーストしたコードを顕在化 プログラム全体での重複チェックを行う 現在は、オープンソース化されている更新終了しています。利用してるPythonのバージョンも古いです。注意が必要です。

CCFinderX デモ簡単なデモを行いました。

Cppcheck 静的コード解析によるエラーチェック 未初期化変数の警告 バッファオーバーラン、メモリリークの検出 STLの正しい使用法の警告現在、活発にアップデートをしています。商用のものが使用できない方におすすめです。

Cppcheck デモ簡単なデモを行いました。

メトリクス計測を始めましょう 明らかに悪い部分を自動的に発見可能 客観的に数値化される リファクタリングを行う明確な基準ができる ソースコードの品質を一定以上に保てる主観的評価では、人を納得させるのは難しいです。特にベテランは・・・

計測できないものはコントロールできない Lord Kelvinメトリクス計測関係の本に引用されることが多い言葉です。

品質管理計測必須

チーム制作の授業の概要 前期、後期の半年毎のチーム制作 １チーム５～８名、２０チーム前後 学年を超えたチーム編成 アジャイル開発（XPとScrumをアレンジ）本校の取り組みを紹介しました。

クソース問題アジャイル開発は成功しましたが、ソースコードの質はひどい状態でした。

クソース [kusource] 理解不能で変更困難なプログラムコード。巨大かつ複雑で、重複しているケースも多い。変更するたびにバグが発生し、バグが収束することはない。地方によっては、 uncodeと呼ばれる。ネタです、申し訳ありません。uncodeの「un 」はローマ字読みしてください。

クソース問題SourceMonitorの計測を義務化していたしかし、完成優先でクソースを量産動作させるので精一杯な学生も多いが…コーディング規約を決めることにした！

７つのコーディング規約お尻は掻いてもクソース書くな実際の授業で利用したスライドです。

複雑度１０まで

１メソッド１０ステートメントまで

１クラス１００ステートメントまで

ネスト２段階まで

複合条件２つまで

フィールド４つまで

ソースコードを愛せよ

tweet! ソースコードを愛せよ恥ずかしがらずに、つぶやいてみましょう。

クソース問題コーディング規約のチェックをどうするか？SourceMonitorで全チームチェック？２０チーム以上を毎回計測するのは非効率計測結果を一覧できる仕組みを作ろう！

KuSourceMonitorの作成SourceMonitorのXML出力機能を活用XMLの計測結果を独自に集計しHTML化違反数、違反率の集計表を作成違反しているメソッドのソースコードを抽出

バッチ処理用XML SourceMonitor 計測結果XML KuSourceMonitorコマンドラインによるバッチ処理で行います集計結果HTML

KuSourceMonitor デモ簡単なデモと、使用前、使用後のプロジェクト結果を比較しました。

クソースの顕在化に成功集計結果を共有サーバーにアップ全学生が閲覧可能となるいじめにならないか？という懸念もあった顕在化後、リファクタリングが活発になる

顕在化による効果 クソースがさらされるのは誰でも嫌！ 自尊心、羞恥心に訴える できる学生ほど、プライドが高い チーム間の競争もあった数値化されると燃える！という学生もいました。

他人に見られていることを意識すればコードは美しくなる Moriharu Ohzuネタです。申し訳ありません。

問題を顕在化するのが品質管理の基本です

今後の取り組み 商用メトリクス計測ツールの導入 もっと多くのメトリクス計測が可能 クラス設計のメトリクス計測をしたい！ 高精度の静的解析によるエラーチェックも！本校では、Klocworkの導入に向けて、準備中です。

クラス設計のメトリクス計測 継承の深さ、子クラスの数の計測 フィールド数、凝集性の計測 他クラスとの結合度の計測 明らかに設計が悪いクラスを検出できる商用ツールは強力です。Javaの世界にはフリーでも良いツールが存在します。

コーディング規約の調整理想標準妥協複雑度 5 10 20 ネスト 2 3 4 メソッド長 10 20 40 クラス長 80 160 240今後の課題です。厳しすぎても、ユルすぎてもダメです。

計測によるレビューの注意点 クソースは減りますが・・・ 静的解析にも限界はあります・・・ 油断してはいけません 新人には丁寧なレビューをしてあげましょう！短時間で良いので、レビューしてあげてください。

理想的なコード普通のコードクソース

理想的なコード普通のコード計測によるレビューでは、クソースがなくなるだけです。

計測によるレビューの注意点 明らかに悪い部分を検出するのが目的 理想を目指すなら、人力レビューが必要 人力レビューの効率化にも可読性が必須 クリーンなコードに対して、人力レビューする理想を目指すなら、人力レビューが必要。しかしクソースはレビューする価値がない。

計測によるレビューにより品質の底上げが可能クソースがなくなるだけでも効果はあります。

SourceMonitor からはじめてみましょう！コードを計測する習慣をつけましょう。SourceMonitorは手軽なツールです。

予算があれば Klocwork 導入しましょう！丸紅情報システムズ株式会社展示ブースにて絶賛デモンストレーション中！CEDEC2011の展示ブースにて、デモが行われていました。

まとめ まずは、計測するところから始める 計測により、効率のよいレビューが可能 計測結果を分かりやすく顕在化する 顕在化による効果は絶大！顕在化しないと、意識が変わりません。

保守性メトリクスに関しては、Code Qualityの第７章に詳しい説明があります。

質問に関しては、ohzu@hac.neec.ac.jpにお願いします。

ソースコードを愛せよソースコードを愛していれば、クソースは書けません。

http://kachibito.net	11511
http://www.techgig.com	4384
http://hisakazuhirabayashi.blog95.fc2.com	3409
http://ke-tai.org	2640
http://paper.li	840
http://d.hatena.ne.jp	252
http://news.mynavi.jp	232
http://twitter.com	194
http://tuyaken.com	180
http://www.gamebusiness.jp	155
https://twitter.com	81
http://asiangraphicdesign.collected.info	81
http://us-w1.rockmelt.com	41
http://a0.twimg.com	39
https://twimg0-a.akamaihd.net	32
http://blog95.fc2.com	31
http://wiki.onakasuita.org	26
http://tenkao.tumblr.com	22
http://webcache.googleusercontent.com	21
http://tweetedtimes.com	18
http://cobs.jp	18
http://strawberryj.am	15
http://kurataka.com	14
https://si0.twimg.com	13
http://nuevospowerpoints.blogspot.com	11
http://szkuwa.tumblr.com	11
http://www.onlydoo.com	8
http://b.hatena.ne.jp	6
http://asakusasatellite.heroku.com	6
http://localhost	6
http://cptl.corp.yahoo.co.jp	6
http://webtech.e-news.bz	5
http://www.tumblr.com	5
http://gamebusiness.jp	4
http://www.slideshare.net	3
http://ishinao.tumblr.com	3
http://safe.tumblr.com	2
http://www.netvibes.com	2
http://s-takagi.tumblr.com	2
http://s.news.mynavi.jp	2
http://jp.hanrss.com	2
http://blog.livedoor.jp	2
http://memolane.com	1
http://115.112.206.134	1
http://trunk.ly	1
http://pieonear.tumblr.com	1
http://zootool.com	1
http://www2.multiburst.net	1
http://pc364.am1.sega.co.jp	1
http://www.google.co.jp	1
http://127.0.0.1:4474	1
http://tweetree.com	1
http://cache.yahoofs.jp	1

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

by Moriharu Ohzu on Sep 12, 2011

Accessibility

Categories

Tags

Upload Details

Usage Rights

53 Embeds 24,346

Statistics

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