「このコード読んでおいて」の絶望
入社2ヶ月目。先輩から既存のプロジェクトにアサインされ、こう言われました。
「まずはこのリポジトリのコードを一通り読んでおいて。来週から機能追加してもらうから」
GitHubを開き、src/ フォルダの中身を見た瞬間、目の前が真っ暗になりました。
ファイルが100個以上ある。どこから読めばいいのか分からない。1つのファイルを開いたら、見たことのない書き方（デコレーター、ジェネリクス、高階関数…）のオンパレード。2時間かけて1ファイルも理解できず、「自分にはプログラミングの才能がないのでは…」と本気で落ち込みました。
しかし翌週、先輩がコードの「読み方」を教えてくれた時、私のアプローチが根本的に間違っていたことに気づきました。
間違い：「上から順にすべてを理解しようとした」
新人のコードリーディングでよくある失敗パターンです。
❌ 間違ったアプローチ
1. src/ の最初のファイルを開く
2. 1行目から順番に全行を理解しようとする
3. 知らない構文が出てきて詰まる
4. 次のファイルに行けない
5. 「全然読めない…」と絶望する
先輩は言いました。「小説じゃないんだから、最初から全部読む必要はないよ」
正しいコードの読み方（トップダウン・アプローチ）
ステップ1：「入口」を見つける
どんなアプリにも「ここから処理が始まる」という入口（エントリーポイント）があります。
Webアプリ（Express/FastAPI等）→ ルーティングの定義ファイル
CLIツール → main 関数
バッチ処理 → スケジューラーの設定ファイル
まずこの「入口」を見つけることが最優先です。
ステップ2：「動かしながら」読む
コードを「静的に眺める」だけでは限界があります。
実際にアプリを起動し、自分で操作しながら「このボタンを押したらどの関数が呼ばれるのか」を追いかけるのが最速の理解法です。
# ログを入れて追いかける（最も原始的だが最も確実）
console.log('>>> ここに来た: userController.create');
ステップ3：「全部読まない」勇気を持つ
100個のファイルのうち、
あなたの担当タスクに関係があるのは、せいぜい5〜10ファイルです。
先輩も、プロジェクトの全コードを隅々まで暗記しているわけではありません。必要な範囲を、必要なタイミングで読んでいるだけです。
ステップ4：知らない構文は「名前」だけメモして先に進む
デコレーター @app.route の仕組みを完全に理解する必要はありません。「あ、これはURLとこの関数を紐づけてるんだな」くらいの理解で十分です。深く知りたくなったら後で調べればいい。
✅ 「この関数は何をしているか（What）」を理解する
❌ 「この構文はなぜこう書くのか（How/Why）」を初日から理解しようとする
コードリーディングの便利ツール
- エディタの「定義にジャンプ」機能（Ctrl+クリック / F12）：関数の呼び出し元から定義元へ一瞬で飛べる
-
git blame：その行を最後に書いたのは誰か、どのチケットで変更されたかが分かる -
git log --oneline ファイル名：そのファイルの変更履歴を時系列で追える
先人のコードは「読めないもの」ではなく「まだ読み方を知らないだけのもの」です。入口を見つけ、動かしながら追いかけ、関係ない部分は勇気を持って飛ばす。この3つで、100ファイルのプロジェクトも怖くなくなります。