develop
コードリーディング
コツ
方法

コードリーディングの方法・コツ

はじめに

コードリーディングという技術はエンジニアにとってとても重要ですが、大きなプロジェクトであればあるほど、難易度が上がっていきます。
ここでは、そのような巨大プロジェクトのコードリーディングにおいて必要となる技術、ポイントを解説していきます。

コードリーディングとは

一言で言えば、「名前の調査」です。
ソースコードというものは、「ファイル名・関数名・変数名・型名・ メンバ名」といった「名前」の集合です。
それぞれの「名前」が何を表しているのかを理解することこそが、コードリーディングです。

準備

ripgrep

grepの超高速版です。
使い方はこちらを参照ください。

タグ

タグをつけて、タグジャンプできるようにします。
gtagsが個人的にはオススメです。
インストールはこちらを参照。

ディレクトリ構造の理解

どのように分割されているかを理解します。

ファイル名から処理内容を推測

ファイル名は衰えないコメントのようなものです。

読みたい場所を決める

巨大なプロジェクトを全て読むのは難しいので、まずは「どこを読みたいか」を考えます。
例えば、「あのバグに関係のある場所」とか「この機能を追加するのに理解する必要のある場所」とか。

読みたい場所を見つける

読みたい場所を決めたら、実際にそこを見つけます。

・ripgrep

キーワードで全文検索します。
(例)
rg [keyword] #通常検索
rg -w [keyword] #単語検索
rg -i [keyword] #大文字小文字無視

・タグジャンプ

目ぼしい関数や変数などを見つけたら、推測通りの存在かどうかをタグジャンプを利用して確認していきます。
このタイミングで、以下で解説する「実際の"読む"技術」が必要になっていきます。

コードリーディング技術

データ構造の理解

ここでは、データ構造とは構造体/クラスの構造を指します。
データ構造の理解は、ソースコードの理解に大いに役立ちます。

関数は呼び元を見て使われ方を知る

知らない関数が出てきても、いきなり中に潜るのではなく、呼び元での使われ方を先に見てみます。
そこから推測を立てられれば関数の中を見なくても済みます。

コールグラフ

関数呼び出しの関係図を描きます。
ソースコードに書いてある呼び出し関係をそのまま図にしたものを静的コールグラフ、実際に動作させたときに呼び出した関数だけを書いた図を動的コールグラフと呼びます。
関数の数がそれなりにあり、 しかも関数呼び出しが深いときに、役立ちます。
逆に、そうでないときはあまり役に立たないかもしれません。
お勧めのコールグラフ描画ツールは、graphvizです。
使い方はこちらを参考にしてください。

読まない

できるだけ読む量を減らす努力をすることが重要です。
詳細は後述

読まない技術

基本的に(ファイルの)下の方にあるものほど重要です。

・変数宣言は飛ばす

というか読み流す。
使われる時に確認するだけで良いです。

・上の方で宣言されている関数は飛ばす

上の方で宣言されている関数は、下の方で宣言されている重要な関数のための部品である可能性が高いです。
なので、上の方で宣言されている関数ばっか読むのは時間の無駄になることが多いです。

・長い関数の上の方の処理は飛ばす

長い関数の場合、一番下で呼ばれる関数一つのための準備が延々と書かれている、なんてザラにあります。
この場合は一番下で呼ばれる関数一つだけを読みましょう。

・関数名から処理を推測

関数の名前は処理の要約です。
なので、その名前から内部の処理が推測できれば、中身のコードを読む必要はありません。
ただし、関数名が嘘を言っている可能性もるので注意してください。
「一度決めたら後から改名できなくなってしまったので名前を変えずに処理を追加した」など、かなり有名なプロジェクトでもわりと多くの頻度で嘘があります。
関数名から関数の処理を推測できない場合かもしくは推測が間違ってそうな場合はちゃんと中身のコードを読みましょう。
この時一番注意しなければならないことは「重要そうではない関数名の関数が重要な処理をしている」という場合が存在することです。

・例外処理は飛ばす

例外処理は読む必要ありません。
飛ばしてしまいましょう。
例外処理を例外処理だと気付く技術がとても重要になります。
条件分岐がでてきたら例外処理か否かを一度考える癖をつけておきましょう。
また、例外処理は、大体上の方にあります。
特にelseなどがある場合の上位のifには注意してください。

・Switch文は簡単そうな一つを選んで読んでみる

Switch文でたくさんのcaseがある場合では、まず上から読むというのは悪手です。
たくさんのcaseの中から一番簡単そうなものを選び、そこだけを読んで全体のswitchの意味合いを推測します。

コーディング

プルリクなどを行う場合は、書き方を真似ましょう。

参考

http://loveruby.net/ja/misc/readingcode.html
https://www.slideshare.net/satorutakeuchi18/viewing-source-code
https://qiita.com/suzutsuki0220/items/15a810fa5eed7356efda
http://boukenki.info/sorce-code-oikata-yomikata-houhou-kotu-matome/
https://gist.github.com/taichi/2693387