🤔

ソースの読み解き方についてのメモ

2020/09/20に公開

Webアプリのソースの読み解き方について、簡単にコツをまとめたものです。

前提

  • プログラムは書いてあるとおりにしか動かないし、書いてあるとおりに正確に動く
    • 気持ちでは動かない
    • 決めつけてはいけない

コツ

  • そもそも頭からお尻を順番通りに読むとは限らない。
  • 例えば旧来のプログラムであればメインループとかイベントループみたいな、待ち受け状態というか骨になる部分をまず掴む。(宣言的な場合は、必ずしもそのようなループ処理は無い)
  • webアプリの場合はエンドポイントがだいたいイベントで、それに沿って理解する。(宣言的な場合の読み方もこちらに近い)
  • コードを読む前に、APIとかエンドポイントの一覧を見て、そもそもの目的や機能性を掴む。
  • トランザクションとマスターをざっくり定性的に分ける。そのうえで、ドメインやユースケースのような観点を持って処理を読む…その処理の目的・意味を考えながら。
  • 一つのエンドポイントを追いかける時は、あまり長くないなら素直に頭から読む方がはやい。
  • 抽象クラスの中とかでやっている事は、そもそも共通する処理とかだから、多くの場合それは最初は追いかけなくてよい(ログ出力とかDB接続の作法は具体的な低いレイヤーのコードなので、最初に読むべき場所じゃない)
  • DIとかでよくわからないクラスが渡ってきている時は、そのクラスの渡し方がフレームワークで定まっているはず。
  • どのような方法でコーディングする場合であっても、そのコーディングの方法を定めた人は、何らかの観点で単純作業の繰り返しに近づくように考えて設計をしているはずである。その思想=どのような事がフレームワーク等で簡略化されているのか、という事を理解する。
  • わからなかったらデバッグで止めてスタックトレースや中身を見る、最悪は追いかける。
  • CRUDを意識して、DBの何を参照して何が起こるかを読む。
  • そのエンドポイントの主にやりたい事が、登録・更新・削除・一覧・詳細・複雑な更新のいずれにあたるかという観点で見る。
  • 異常系と正常系を意識して、まずは正常系を追いかける。
  • 一般にバリデーションをどこかでやっているはずだが、しかしそれは後で読む。
  • 全体的に、まずはあるエンドポイントを選んだ時にその内容を一言で説明できる状態を目指して、必要ならそれを深く説明する。
  • 関数の名前は、直感が働くほど読んでないうちは名前から類推できないから、追いかける。
  • 関数やサブルーチンを読む時は、副作用がないかを注意して読む。
  • webアプリの前提としては、基本的にDB(キャッシュサーバなども含む)にアクセスして必要なら更新してレスポンスを返すのがメインなので、まずそれか否かを見る。
  • よく見かける共通の作法に着目する。
  • DBのリレーションに注意して読む。親子関係(外部キー)など。

Discussion