私はこうやってコードを読む - プログラマyasuhoの隠れ家

コードリーディングって、プログラマの必須能力だと思うんだけど、その方法論などを書いた本って、ほとんど見たことないんだよなあ。ていうか、もしかすると説明しにくいのかも。

ソースコード理解と勉強会というタイトルでお話をした。ソースコードを読むことの意義などを話した後、わたしのしょぼいテクニックを恥ずかしながら披露した。
2010-01-31 - 未来のいつか/hyoshiokの日記

プログラムをうまく書くことが出来るようになる一番の近道はとにかくいろいろなコードをたくさん読むことだと思う。言語仕様やAPIリファレンスを読んで自分で書いだけでは、上達するのは難しい。まずはサンプルを読むことから始めることが多くない！？それだってcode readingだよね。

ソースコードには先人のノウハウや考えがいっぱい詰まってる。コードを読まない限り、何がよくて何が悪いかだって分からない。個人的にはコードを読むことはとても楽しい。その人がどんなことを考え、どんな思いで書いたかをうかがい知ることが出来るから。

コードの読み方については過去の記事でいろいろ書いたので、興味のある方はどーぞ。

上記記事にはyasuhoの読み方が書いてなかったよーな気がするので、ちょっと書いてみる。これがいいやり方なのかどうかは分からないけど、もしかすると参考になるかもしれないってことで。:)

まずはAPIの入り口とか外部インタフェースの部分から読み始める。インタフェースの部分はその先が想像しやすいし、取っ掛かりとしてやりやすいから。

そのようなインタフェースがないプログラムの場合は、機能の中核と思える部分を探し出して、読み進める。

読む前のツールの準備も大事。関数やデータの参照先・実体をサーチしながら読むツールなどを使うと、読むのがすごく楽になるから。

コードを読み進めていくと、ソースファイルやディレクトリごとの役割が分かってくるので、機能単位に読み始める。必要であれば簡単なメモを作成。

一つのコンポーネントのリーディングに時間をかけ過ぎると全体像がぼやけてしまうので、要点だけ理解したらさっさと次へ。

基本的に全体のイメージを掴むことに集中する。一つのところにあまり時間をかけないように心がけてる。

構成や流れが分かりにくい時はデバッガでブレークポイントをかけ、スタックトレースを見たりデータを見たりする。デバッグ環境がない場合は机上でシミュレートしてみる。

関数名・変数名・コメント。その他何でも名前から機能が想像できるところは使いまくる。中にはそういうのがあまり使えないカオスなプログラムもあるけど（笑）

読む時はコードを書く時と同じで、外部の割り込みはdisableしつつ読むことに集中する。できればメールも切る。

とはいえ、あまり長い時間は持続できないので、適当に休憩。集中力が足らないんですな、きっと（笑）

あとはぜひ他の人の読み方やノウハウも聞いてみたい＆見てみたい。もし機会があれば、こんな集いに参加してみたいですねー。