仕事で全然ソースコードが読めず、大変なのでソースコードの読み方を自分なりにまとめてみた。
ソースコードを読むとは
良く分かっていないが多分次のようなことだと思う。
- プログラムの意味をイメージできること
- プログラムを書いた人の意図をイメージできること
読む前にやること
事前に行っておくことで読むことに集中できる。
- 読む目的を明確にする
読む時点で分からないこと、覚えておくことを極力減らす
- 専門用語
- 略語
- 技術的知識
事前知識を付ける
- 仕様書
- 設計書
- コード規約
- アプリケーションの構造について聞ける人がいれば聞く
- ドメイン知識
- プロジェクトのルール
読む心構え
できるだけ効率良く、負荷を少なく読むための心構え。
何が知りたいのかを明確にしておく
- 目的以外のソースは読まない
- ソースコードに物語はない
- 小さな処理の集まりであることを意識
- 必要な部分だけ、必要な時に読む
完璧主義を捨てる
- システム全体を理解することは無理
- 読み始めは作った人を信じて深い処理や共通処理は読まない
- 読んでも分からない処理は深追いしない
読むべきソース、読まなくていいソースを分ける
- 読むソース
- メソッドの呼び出し先の直下ソース
- 読まなくてよいソース
- メソッドの呼び出し先のから呼ばれているメソッド内のソース
- 共通系の処理(複数の場所から呼ばれている処理)
- 元々あるメソッド化された処理
- 読むソース
当てずっぽうではなく、確かなものを手掛かりにする
- 表示ページ等の描画されているもの
- ボタン等のトリガー
- サーバーのログ
- DevToolsで表示される情報
どこから読むのか
読み始めていくポイント。
フロントエンドから見る
- HTMLタグの
idを見つけてエディタで検索 - UIのトリガーを起点に少しずつ潜っていくイメージ
- HTMLタグの
イベントが発生する場所から読み始める
- イベントをトリガーにしていない機能は殆ど無い
処理の起点を探す
- 必ず処理の起点となる実行ファイルがある
- 起点のファイルから呼ばれているメソッド等を読み始める
どう読むのか
メモを取りながら大枠と詳細に分けて読むと良さそう。
メモを取る
手書きでも、エディタも良いのでとにかくメモを取る。 図なんかは手書きで書いていった方が早くてよさそう。
- フローチャート
- クラス関係図
- 関数呼び出し関係図
- データ構造図
- コード行数
- メソッドの繋がり
大枠を読む
ボヤッと全体のイメージを掴む。
ディレクトリ構造から大枠を掴む
- モジュールの関係性
- プログラムがどのように分割、構成されているのか
- ファイル名、関数名から処理をイメージする
プログラム全体の枠組みを理解する
- 欲しい情報がどこにあるのかイメージできる状態
- ファイル、ディレクトリ
- 処理の起点になるファイル
- 欲しい情報がどこにあるのかイメージできる状態
データ構造を知る
- データの流れ
- データの入出力
クラス名、関数名から処理を推測しながら読む
- クラス名、関数名だけ見て中身は信じて読まない
詳細を読む
実装に関連する情報をたくさん集めるイメージ。
- デバッガで直接値を確認する
- 値を確認しながら読んだ方が理解が早い
- 書いた人の意図をイメージしながら読む
- 処理対象周辺は読み飛ばさない
- 不要なコードをコメントアウトする
- 読む対象、処理を絞り込む
- 不要な情報はノイズ
オブジェクト指向言語の読み方
オブジェクト指向がそもそも自信ないけど...
- オブジェクト指向言語の読み方
- 上から下に読むものではない
- オブジェクトのスコープを意識(何がどこまで影響するのか)
- 処理単位で読む時にはオブジェクト同士の関係性を意識する
- オブジェクトはネットワークのような関係性(多方向)
読めない時の対策
読めない原因を探し、必要な情報をキャッチアップした上で再チャレンジ！
感想
ソースコード読めないのは最初は誰でも同じだと思うので、はやくこの壁を乗り越えたい。 逆に言えばソースコード読めるようになれれば何でもできそうな気がしているのでがんばっていきたい。
