オルタナティブ・ブログ > 森崎修司の「どうやってはかるの?」 >

計測できそうでできない多くのこと。エンピリカル(実証的)アプローチで。

「経験があればコードレビューは速くなるか?」を調査した研究結果

»

去年の1月にソースコードリーディングワークショップというイベントを開催しました。小規模なソースコードを多くの実務者の方に読んでいただき、時間や傾向を得ようというものです。詳細は@ITの記事や本ブログの過去エントリを参照ください。

分析結果の1つである「経験や読み方によって読解時間が短くなったり読解者の理解度は上がるか?」という検証の結果を日経SYSTEMS 2011年12月号「検証ラボ」の記事として寄稿しました。

分析結果が得られるまでは、経験があれば読解時間が短くなったり理解度は高くなるのが当たり前と考えていたのですが、経験は読解時間には影響するものの理解度にはそれほど大きく影響しないという結果を得ています。詳細は記事をご覧いただくとして、下のような条件で調査・分析しています。

検証の協力者には、GUIアプリケーション(お絵かきツール)のバージョン1.0(Javaで1600行程度)を理解していただき、その後複数の変更仕様とそれに対応するソースコード差分を読解(レビュー)していただきます。変更仕様には間違いがないとして、差分ソースコードが変更仕様を満たすかどうかを判断いただき、その判断理由を書いていただきます。判断に必要となった時間を協力者に記入してもらい、協力者の判断結果と理由から理解度を推測しています。

判断結果と理由の間で矛盾があれば、理解度cとし、おおむねほとんどの場合(正常系)で問題がなければ理解度b、詳細な部分や例外的事象(異常系)の場合への言及があれば理解度aとしています。たとえば、GUIコンポーネントに関する変更で、多くの場合で問題がなければ理解度b、プラットフォーム依存の部分で将来的に問題が起こる点まで指摘されていれば理解度aといった具合です。

これらに加え、協力者の経験(プログラミング経験、GUIプログラミングの経験、これまでに携わった開発規模(プロジェクト全体))と読み方のアプローチ(ソースコードを紙面に印刷し読む、画面上で検索機能のあるビューアやエディタで読む)、読解方針(1行ずつコードを読んで局所理解を優先する、クラス図等から全体理解を優先する)によって、読解時間の傾向や理解度が影響を受けるか分析しています。

もし日経SYSTEMSがお近くにあれば、ご覧ください。
こちら(日経SYSTEMSのオンライン購入サイト)で記事のPDFを購入することもできるようです。

今回の記事は、田口氏、西薗氏の論文を中心に記事化したものです。ワークショップの開催にあたって数多くの方にご支援いただきました。他の論文成果を含め、お礼をまとめたいと思っています。

分析には時間がかかるので、なかなかすぐにはできませんが、研究グループ一同、何らかの形でご協力者の方々やソフトウェア開発に携わるエンジニアの方々にフィードバックできればと思っています。

Comment(0)