ハンズオンの題材
参加者は、自分の所要時間と他の参加者の平均的な所要時間や分布とを比較することで自身のスキル確認やスキル向上に役立てることができるでしょう。ハンズオンは期間限定で、以下を用意しています。図2は結果が公開された後で自分の所要時間と比較している様子を表しています。
- （a）ペイントツール ver. 1.0のJavaアプレットとソースコード（約1,500行）
- （b）ver. 2.0のソースコードとver. 1.0のソースコードの差分（diff（パッチ）形式、19項目）
また、以下の手順で実施します。
- 記録フォーマットの入手
- （a）の理解
- （b）の適用可否の判断
- 記録フォーマットの送信
記録フォーマットをダウンロード、簡単なアンケートに答える。
（a）のソースコードを読み、どの部分でどのような機能が実現されているかを把握する。そのときの所要時間をフォーマットに記録する。
（b）の差分19項目それぞれについて（a）に反映しても問題ないかをソースコードを読んで判断し、その理由をフォーマットに記録する。そのときの所要時間を記録する。
記録したフォーマットをメールで送信する。ハンズオン終了後の集計結果の通知はそのメールアドレスに送られる。
図3に、（a）,（b）の例を示します。例のために非常に小さくすぐに理解できるソースコードとしていますが、実際のハンズオン題材はもう少し複雑で行数も多いプログラムです。図3の（a）は文字列配列argsとして与えられた2つの整数の和を返すメソッドです。（b）では、引数の個数をチェックする部分が追加されています。参加者は、（a）を理解し、（b）にバージョンアップしてよいかを判断します。（b）をバージョンアップ版としてよいでしょうか？ 答えは「（b）にバージョンアップしてはいけません」。このメソッドに渡された引数argsが2つの文字列配列であるかどうかをチェックし、2つでない場合にはゼロを返しています。しかし、これでは、計算結果がゼロなのか、与えられた文字列配列argsが2つではなかったかどうかがわかりません（他にも文字列として渡された値が整数でなかった場合など検討すべき点がありますが、返り値がゼロのときの問題があるので、バージョンアップはできません。また、このようなエラー処理の場合、Exceptionを利用するのが一般的であり、保守性の面でも好ましくないバージョンアップと言えそうです）。
このような形で、バージョンアップしてよいかどうかを判断することにより、ソースコードの理解度合い、所要時間を測ります。
(a) ver. 1.0のソースコードの例
public int sum(String args[]) {
int number1, number2;
number1 = Integer.parseInt(args[0]);
number2 = Integer.parseInt(args[1]);
return number1 + number2;
}
(b) ver.2.0のソースコードの例
public int sum(String args[]) {
int number1, number2;
if (args.length != 2) return 0;
number1 = Integer.parseInt(args[0]);
number2 = Integer.parseInt(args[1]);
return number1 + number2;
}
(b) ver.2.0とver1.0の差分(diff形式) @@ -2,0 +3,2 @@ + if (args.length != 2) return 0; +
ハンズオン結果の公開方法
結果は参加者の個人情報を削除した上で公開します。ハンズオンに協力していただいた方には、結果報告専用のWebページのID, パスワードを配布し2009年中に詳細な結果をお知らせする予定です。結果は図4のような、所要時間の傾向、自由記述部分の集計を予定しています。図4中の分布を見れば、ご自身が得意なもの、平均的なもの、不得意なものを知ることができるでしょう。また、図4中の表のような集計結果を見ると、他の参加者がどのような観点でソースコードを読み進めたかを知ることができるでしょう。
結果の回収はなるべく個人情報を含まない形で行い、集めた結果（アンケート、所要時間、理由など）は個人が特定できない形にした上で論文、プレゼンテーションなどの形で公開します。また、（b-2）の適用判断結果、入力ミスなどの情報から、ベンチマークデータへ反映しない（特異値として扱う）場合もあります。
公開データは所要時間とアンケート項目から作成し、プログラミングの経験年数、コードレビューの経験、利用ライブラリを使った開発経験の有無、などで理解に必要となった時間の分布を作成します。参加者は、それをもとに「自分と同程度のプログラミング経験を持つ参加者の所要時間」「自分と同程度のコードレビューの経験をもつ参加者の所要時間」などがわかり、自身のスキルの位置づけや強化すべき部分を決める際の参考とできます。
ハンズオンには今すぐ参加できます。『コードレビュー オンライン ハンズオン』のサイトをご覧ください。
オンラインハンズオンの結果をもとにした研究
ハンズオンの結果は、ソースコードの差分（パッチ）とその理解に必要な時間（コスト）との関係を明らかにする研究テーマの題材にもなります。差分ソースコードを（半）自動解析することで、理解に必要な時間を予測することが最終的な目標です。まず、差分ソースコードを変更タイプ、ソースコードメトリクス（ソースコードを規模や複雑さなどの観点で数値化したもの）、変更波及範囲などから整理し、ソースコード理解に個人差が大きく関与するもの、そうでないものを明らかにする予定です。次に、個人差が小さいものについて、ソースコードの特徴と理解に要する時間との関係を探っていく予定です。
多くのソフトウェア開発が保守開発、派生開発となっている現状では、研究結果は計画、見積り、妥当性評価の際に役立つことが期待されます。たとえば、「基底クラスの変更は派生クラスの変更よりも理解に時間がかかり、子クラス数（派生しているクラス数）の指数倍になる」「メソッド追加はクラス変数の変更と比較すると理解に要する時間が短く、追加行数が少ないほど短時間で理解できる」「差分の適用先の範囲が広範囲に分散しているものはそうでないものと比較して、理解するのに時間がかかり、その時間は範囲の大きさに比例して大きくなる」といった関係を得ることを目指しています。
そのような関係が得られれば、実際にはまだ変更をしてないソースコードであっても、どの部分にどのような変更が必要かを見積るだけで、確認のための時間を予測できるようになります。さらに、結果の正答率を用いれば、どのような場合に変更を見落としてしまう傾向があるかを明らかにできるかもしれません。他にも、多くの人が間違いやすい部分は、多くのレビューアでレビューをしたり、間違いの少ない部分の確認は、手分けして実施したりするなど、コードレビューの計画、所要時間の見積りなどに役立てることができます。
せひ奮って、オンラインハンズオンにご協力ください。
