読者参加型企画（AD）

【読者参加型企画】2,000行のJavaソースコードを読むのに何分かかりますか？

～ソースコード理解とパッチ適用判断問題で腕試し～

2009/09/11 16:00

　コードレビューなどで、他の人のソースコードを読んだり理解したりする速度が気になることはありませんか？私たちの研究グループで実施した観察でもソースコードを読む速度は個人差が大きいことを確認しています。この読者参加企画では、オンラインのコードレビューハンズオンにご協力いただくことで、ご自身のスキル確認やスキル向上に役立ていただくとともに、研究にも活用させていただくことを期待しています。

ソースコード読解力は個人差が大きい

　コードレビューなどで、他の人のソースコードを読んだり理解したりする速度が気になることはありませんか？また、読む速度や理解する速度がとても速い人がいると感じたり、自分が周りの人よりも速いと思ったりすることがあるのではないでしょうか。私たちの研究グループで実施した観察でもソースコードを読む速度は個人差が大きいことを確認しており、同じソースコードを理解するための時間に6倍の差がある事例を確認しています。

　では、自分自身のソースコードを読む速度や理解する速度が、平均と比べて速いのか遅いのかを知るためにはどうしたらよいでしょうか？最も簡単な方法は、社内などの身の周りの人とコードレビュー時間を比べてみることでしょう。他にも、参加者全員でソースコードを読むような社外勉強会に参加する方法もありそうです。

文献からは大まかな速度を知ることができる

　書籍、標準、論文の情報も参考になるでしょう。表1は国際標準や文献に掲載されているコードレビュー速度の一覧です。文献によっては、プログラミング言語が明記されていないものもあります。他にも、どのようなプロジェクト、前提、手順で実施したものかも勘案する必要があるので、これらのコードレビュー速度は大まかな指標として捉えるのがよいでしょう。

表1　標準や文献での参考値

文献名	コードレビュー速度（1時間あたり）	公開年
IEEE: IEEE Standard for Software Reviews and Audits（1028-2008）	100～200行（Technical reviews）	2008
ワッツハンフリー: TSPi ガイドブック（Introduction to the Team Software Process）、秋山義博監訳、JASPIC TSP研究会訳、翔泳社	200行以下（インスペクション）	2008（1999: 原著）
M. Fagan: "Design and code inspection to reduce errors in program development", IBM Systems Journal, vol. 15, No. 3, p 181-211	700～900行（問題発見）、500～700行（問題指摘）、（インスペクション、COBOL, コメント行含まず）	1976

ハンズオンワークショップでの事例

　私たちの国際研究グループが主催した「ソフトウェアインスペクションワークショップ2009」では、レビュー観点をセキュリティに限定し、1時間10分で4,500行のJava言語から欠陥の発見をするハンズオンを実施しました（図1）。ワークショップ参加者は、実務でソフトウェア開発に携わる様々な企業に所属する方です。事後アンケートから、参加者93名のうち32名が普段の業務でのコードレビューのほうが速い（時間当たりに読み進めるソースコード量が多い）と回答しました。表1の値とはずいぶん異なりますが、特定の観点に限定することで読むべき部分を限定し、みかけ上の読む速度が上がることもあると考えることができそうです。

図1　ワークショップでのレビューの様子
（この後、参加者どうしでグループディスカッションをしました）

オンラインでもハンズオンワークショップを

　紹介したハンズオンのアンケートをはじめ「オンラインでもできるものを」という要望をたくさんいただいています。そこで、対象ソースコード、読みすすめ方など、条件をある程度そろえ、参加者の結果を共有できる題材（ハンズオン題材）を用意することを考えました。ハンズオンは、参加者にとっては腕試し、私たち研究グループにとっては研究題材になります。題材の準備や研究テーマは奈良先端科学技術大学院大学博士前期課程の保田裕一朗氏が中心となって進めています。

ハンズオンの題材

　参加者は、自分の所要時間と他の参加者の平均的な所要時間や分布とを比較することで自身のスキル確認やスキル向上に役立てることができるでしょう。ハンズオンは期間限定で、以下を用意しています。図2は結果が公開された後で自分の所要時間と比較している様子を表しています。

（a）ペイントツール ver. 1.0のJavaアプレットとソースコード（約1,500行）
（b）ver. 2.0のソースコードとver. 1.0のソースコードの差分（diff（パッチ）形式、19項目）

図2　ハンズオン終了後に公開される結果と自分の所要時間を比べるとスキル診断に

　また、以下の手順で実施します。

記録フォーマットの入手

記録フォーマットをダウンロード、簡単なアンケートに答える。

（a）の理解

（a）のソースコードを読み、どの部分でどのような機能が実現されているかを把握する。そのときの所要時間をフォーマットに記録する。

（b）の適用可否の判断

（b）の差分19項目それぞれについて（a）に反映しても問題ないかをソースコードを読んで判断し、その理由をフォーマットに記録する。そのときの所要時間を記録する。

記録フォーマットの送信

記録したフォーマットをメールで送信する。ハンズオン終了後の集計結果の通知はそのメールアドレスに送られる。

　図3に、（a）,（b）の例を示します。例のために非常に小さくすぐに理解できるソースコードとしていますが、実際のハンズオン題材はもう少し複雑で行数も多いプログラムです。図3の（a）は文字列配列argsとして与えられた2つの整数の和を返すメソッドです。（b）では、引数の個数をチェックする部分が追加されています。参加者は、（a）を理解し、（b）にバージョンアップしてよいかを判断します。（b）をバージョンアップ版としてよいでしょうか？答えは「（b）にバージョンアップしてはいけません」。このメソッドに渡された引数argsが2つの文字列配列であるかどうかをチェックし、2つでない場合にはゼロを返しています。しかし、これでは、計算結果がゼロなのか、与えられた文字列配列argsが2つではなかったかどうかがわかりません（他にも文字列として渡された値が整数でなかった場合など検討すべき点がありますが、返り値がゼロのときの問題があるので、バージョンアップはできません。また、このようなエラー処理の場合、Exceptionを利用するのが一般的であり、保守性の面でも好ましくないバージョンアップと言えそうです）。

　このような形で、バージョンアップしてよいかどうかを判断することにより、ソースコードの理解度合い、所要時間を測ります。

図3 ハンズオン対象のソースコードの例

(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）の適用判断結果、入力ミスなどの情報から、ベンチマークデータへ反映しない（特異値として扱う）場合もあります。

　公開データは所要時間とアンケート項目から作成し、プログラミングの経験年数、コードレビューの経験、利用ライブラリを使った開発経験の有無、などで理解に必要となった時間の分布を作成します。参加者は、それをもとに「自分と同程度のプログラミング経験を持つ参加者の所要時間」「自分と同程度のコードレビューの経験をもつ参加者の所要時間」などがわかり、自身のスキルの位置づけや強化すべき部分を決める際の参考とできます。

　ハンズオンには今すぐ参加できます。『コードレビューオンラインハンズオン』のサイトをご覧ください。

図4　集計結果の報告予定（一部抜粋）

オンラインハンズオンの結果をもとにした研究

　ハンズオンの結果は、ソースコードの差分（パッチ）とその理解に必要な時間（コスト）との関係を明らかにする研究テーマの題材にもなります。差分ソースコードを（半）自動解析することで、理解に必要な時間を予測することが最終的な目標です。まず、差分ソースコードを変更タイプ、ソースコードメトリクス（ソースコードを規模や複雑さなどの観点で数値化したもの）、変更波及範囲などから整理し、ソースコード理解に個人差が大きく関与するもの、そうでないものを明らかにする予定です。次に、個人差が小さいものについて、ソースコードの特徴と理解に要する時間との関係を探っていく予定です。

　多くのソフトウェア開発が保守開発、派生開発となっている現状では、研究結果は計画、見積り、妥当性評価の際に役立つことが期待されます。たとえば、「基底クラスの変更は派生クラスの変更よりも理解に時間がかかり、子クラス数（派生しているクラス数）の指数倍になる」「メソッド追加はクラス変数の変更と比較すると理解に要する時間が短く、追加行数が少ないほど短時間で理解できる」「差分の適用先の範囲が広範囲に分散しているものはそうでないものと比較して、理解するのに時間がかかり、その時間は範囲の大きさに比例して大きくなる」といった関係を得ることを目指しています。

　そのような関係が得られれば、実際にはまだ変更をしてないソースコードであっても、どの部分にどのような変更が必要かを見積るだけで、確認のための時間を予測できるようになります。さらに、結果の正答率を用いれば、どのような場合に変更を見落としてしまう傾向があるかを明らかにできるかもしれません。他にも、多くの人が間違いやすい部分は、多くのレビューアでレビューをしたり、間違いの少ない部分の確認は、手分けして実施したりするなど、コードレビューの計画、所要時間の見積りなどに役立てることができます。

　せひ奮って、オンラインハンズオンにご協力ください。

この記事は参考になりましたか？