【新人なるプログラマーへ】ソースコードを読みましょう：小山博史のJavaを楽しむ（10）（1/2 ページ）

教育界、技術者コミュニティでJava言語の教育と啓蒙に長年携わってきた筆者が、独自の視点からJavaの面白さを掘り下げていく。（編集部）

[小山博史，ガリレオ]

　新しい年度になって、もうじき新人の皆さんが現場に行く時期になってきました。大きな会社であれば、新人研修があって、その後に配属となりますから、実際に現場で活躍するようになるまでには、まだまだ時間があるかもしれませんが、小さな会社であれば即戦力として期待され、早速開発に参加することになるのではないでしょうか。

　ということで、今回は新人の皆さん向けに、プログラミング技術上達の方法として、「ソースコードを読むこと」について語ってみたいと思います。

ソースコードを読むのって、どんなとき？

　新人の皆さんは、「ソースコードを読もう！」といわれたときに、どういうことを想像するでしょうか。「プログラムの参考書などを購入して、そこに掲載されているサンプルのソ−スコードを読むのかな」と思う人が多いのではないでしょうか。もしくは、「自分が作成したソースコードを何度も見直して、実行時に問題が発生しないかどうか検討するということなのかな」と思うかもしれません。

　ここでは、それらのソースコードを読むことも含めて話をしますが、ほかにも、開発チームのほかの人が書いたソースコードを読むことや、オープンソースのコードを読むことについても考えてみたいと思います。

中心となる開発者の書いたソースコードをお手本に読む場合

　筆者の経験では、チームで開発をするプロジェクトでは、中心となる開発者（コアデベロッパー）がソフトウェアの中心／核／礎となるソースコードを書き、それを参考にしたり、マネをしながらほかの開発者（デベロッパー）が周辺のプログラムを作成するといった開発に参加したことがあります。

図1　コアデベロッパー中心の開発スタイル

　フレームワーク部分や共通ライブラリとして使われるプログラムをコアデベロッパーが作り、「プラグイン」プログラムやフレームワークのAPIをどう使うのかのサンプルとなるような簡単な機能も同じコアデベロッパーが作成するわけです。デベロッパーはコアデベロッパーが作成したプログラムのソースコードを読んで、自分が担当する機能を「プラグイン」として実装したり、フレームワークへ載せるプログラムとして作成したりすることになります。

既存のソフトウェアを修正・変更する場合

　また実際の業務上、既存のソフトウェアのバージョンアップやバグを治す機会も多々あるかと思います。そういった場合は、いかに“速く”ソフトウェアのロジックや動きを把握してソースコード中の修正／変更する部分をピンポイントで見つけ出すかも重要になってくると思います。

ウォークスルーをする場合

　ソフトウェア工学について勉強したことがあれば、システム開発の工程の1つに「ウォークスルー」というのがあるのはご存じでしょうか。

図2　ウォークスルー

　この方法では開発チーム全員でソースコードのレビュー（評価、確認）をするので、そのときにソースコードを読む必要があります。複数の目で、処理の流れを確認することにより、1人では気付きにくいミスを発見することが期待できます。

リファクタリングをする場合

　また、最近は「リファクタリング（単純に説明すると、コードの修正によるソフトウェアの再構築、読みにくいコードを読みやすく洗練されたものに改善するなど）」をするためにソースコードを読むこともあります。

図3　リファクタリング

　ちょっと前までは、「動いているコードは触るな」という常識がありましたが、TDD（テスト駆動開発）などでは、互換性を確保するためのテストを必ずすることを前提としたリファクタリングが推奨されていて、改善が必要なコードは積極的に修正するようになってきています。リファクタリングに当たっては、既存のコードを読んだうえで改善をすることになるので、その場合もソースコードを読むことになります。

編集部注：TDD（テスト駆動開発）について詳しく知りたい読者は、記事「プログラムを書く前にテストを先に書くことの利点」をご覧ください。

オープンソースを使っている場合

　オープンソースのソフトウェアを使っているときに、うまく動かないことがあると、どんなエラーが発生しているのかを調べて、開発ホスティングサービスなどにあるソースコードをチェックするということもあります。

編集部注：開発ホスティングサービスについて詳しく知りたい読者は、記事「ソースコードの宝石箱、●●Forgeを見逃すなかれ」をご覧ください。

図4　オープンソースの使用

　オープンソースソフトウェアだと、ライセンスに同意すればソースコードを読むことができるので、ちょっとしたエラーなら、自力で応急処置をしておき、後で正式なパッチ（修正プログラム）を当てるといった方法もできるというのが魅力です。

ソースコード読む機会はたくさんある

　このように、ちょっと考えただけでも、ソースコードを読む機会というのは多くあります。こうしてみると、プログラミング言語を勉強したてのころはあまり気が付かないものなのですが、「ソースコードを読む」という能力は意外と重要だと分かるはずです。

ソースコードを読む能力はプログラマーの“基礎能力”

　さて、「ソースコードを読む能力」は重要といいましたが、筆者は「ソースコードを読む能力が上がれば、プログラミング技術上達に直結する」と思っています。これは、「キーボード入力の能力が上がれば、プログラミング技術上達に直結する」といっているのと同じようなものです。

キーボード入力能力も重要

　プログラミング学習において、キーボード入力がたどたどしい人は、サンプルプログラムを入力するだけで時間と気力を使ってしまい、肝心のサンプルプログラムについて理解する時間が足りなくなってしまいます。コンパイルエラーの修正にも、時間がかかってしまいます。

　これが、キーボード入力の速い人は、タッチタイピングでさっと入力してしまいますし、エラーの修正もキー入力のところで戸惑ったりはしません。そうすると、動作確認できるサンプルプログラムの数は、キーボード入力の能力が高い人の方が多くなる傾向となります。

　短い時間で動作確認できるサンプルプログラムの数が多い人の方が、プログラミング技術力が高いというわけではなく、サンプルプログラムを理解できた数が多いかどうかの方が、プログラミング技術力が高いかどうかに影響してくるのですが、ここでは、大ざっぱな感覚としての傾向と考えてください。

　最近のGUI環境のIDE（統合開発環境）ではソースコードの補完機能などがあるので、それを使えば、こういったキーボード入力の能力差は大きな影響はなくなっているとはいえ、ショートカットキーなどによる入力も、結局のところキーボード入力が必要なので、この傾向に変わりはないような気がします。

図5　統合開発環境Eclipseのソースコード補完機能

　ということで、「キーボード入力の能力が高い人の方が、同じ時間内で動作確認できるサンプルプログラムが多い」といえるかと思います。そうであれば、多くのサンプルプログラムを動作確認できる人の方が同じ時間内に多くのことを学べると考えられます。

キーボード入力能力を野球で例えると……

　「キーボード入力の能力」は、野球の世界でいえば基礎能力の部分で、「走れるか」とか「打てるか」とかいった部分だと個人的には思っていますから、この能力が上がれば、プログラミング技術上達に直結するはずです。

　とはいえ、「キーボード入力が速い人ほどプログラミング技術がある」というわけではありません。これは、野球の世界で「走れるからといって良い選手とは限らない」のと同じです。

ソースコードを読む能力の重要性とは？

　ここで、筆者は「キーボード入力の能力」と同じように、「ソースコードを読む能力」も“基礎能力”だと考えています。

　「ソースコードを読む能力」は、「キーボード入力の能力」ほど明確に能力差を測定できないので、説明が難しいのですが、「ソースコードを読む能力」が高ければ、多くの良いサンプルソースコードを読むことができますし、実際に動作しているプログラムのソースコードを素早く分析できるはずです。

　こういう基礎能力が上がれば、プログラミングの総合力は上がるはずだと考えています。

　それでは、ソースコードを読む能力を高めるためにはどうすればいいのでしょうか？ 次ページで、そのヒントをお教えしましょう。