テスター・新規参入者のためのC++コード読解術

### C++の読解を阻む「4大要因」

1. **ヘッダ（.h/.hpp）と実装（.cpp）の物理的分離**:
宣言と中身が別ファイルにあるため、エディタで行き来しているうちにコンテキストを見失います。
2. **多態性（仮想関数・インターフェース）によるジャンプ先の曖昧さ**:
`target->onDamage(10);` と書かれていても、実際に呼ばれるのが `Player::onDamage` なのか `Boss::onDamage` なのか、コードの字面だけでは特定できません。
3. **マクロ（`#define`）とプリプロセッサの地雷**:
プラットフォーム分岐（`#ifdef _WIN32` など）や独自マクロによって、今読んでいる行が本当にビルド対象なのか分かりにくいことがあります。
4. **メモリ所有権の不可視性（特にレガシーC++）**:
生ポインタ `Enemy*` が渡されたとき、「この関数の中で delete されるのか？」「それとも外部で誰かが持ち続けるのか？」がシグネチャだけでは見えにくい点です。

• 「全部読もう」としないのが鉄則: 巨大コードベースを1行目から順に読むのは不可能です。「起点」と「境界」だけを狙い撃ちにして読むのがプロの流儀です。

### 起点1：エントリポイント（`main` または `WinMain`）
すべての処理はここから始まります。まずは `main` 関数を探し、以下の3点だけを確認します。
- **初期化フェーズ**: どんなサブシステム（描画・サウンド・入力・ネットワーク）がどの順序で立ち上がっているか？
- **メインループ（ゲームループ）**: 毎フレーム更新（`update`）と描画（`draw`）を回しているループ条件はどこか？
- **終了・解放フェーズ**: ループを抜けた後、何が破棄されているか？

```cpp
// 典型的なメイン関数の読み解き方
int main() {
// 1. システム初期化：依存の根幹を見極める
Config config = LoadConfig("settings.json");
Renderer renderer(config.width, config.height);
GameManager gameManager(&renderer);

// 2. メインループ：フレーム処理の入口
while (!renderer.shouldClose()) {
float dt = timer.tick();
input.poll();

gameManager.update(dt); // ★ここに潜ればゲーム全体の論理がわかる！
gameManager.render(); // ★ここに潜れば描画フローがわかる！
}

// 3. 終了処理：リソース解放の順序を確認
gameManager.shutdown();
return 0;
}
```

### 起点2：中央管理クラス（`GameManager` / `App` / `Engine`）
`main` の直下にあるメイン管理クラスです。このクラスがメンバ変数として「誰を所有しているか」を見ることで、システムの主要構成要素が一目瞭然になります。

### 起点3：シーン/ステートマネージャ
画面が「タイトル画面」「戦闘画面」「リザルト」のように遷移する場合、`SceneManager` や `GameState` の実装を見ることで、各画面の独立したロジックがどこに隔離されているかが分かります。

### ヘッダファイルこそが最高の仕様書である

C++において、ヘッダファイル（`.h` または `.hpp`）は**「外部に対して提供する機能の契約書（Interface Contract）」**です。
実装（`.cpp`）に書かれているアルゴリズムの詳細を無視し、ヘッダの `public:` 領域だけをスキャンします。

```cpp
// Player.h を開いたときの「プロの視線」
class Player {
public: // ★ここから下だけを見る！
Player(float x, float y);

// 【状態取得】const が付いている＝内部状態を変更しない安全な関数
float getHp() const;
bool isAlive() const;
Vector2 getPosition() const;

// 【状態変更・操作】引数と関数名から副作用（何が起きるか）を推測
void takeDamage(int amount);
void move(const Vector2& direction);
void fireWeapon();

private: // ★最初は読まなくてOK！（内部実装の詳細に過ぎない）
float m_hp;
Vector2 m_pos;
// ...
};
```

#### 読み方のコツ：`const` メンバ関数に注目せよ
`float getHp() const;` のように末尾に `const` が付いている関数は、**「オブジェクトの内部状態を一切書き換えない（読み取り専用）」**という言語仕様上の絶対保証です。
テスターとして「このボタンを押したらHPが減るバグがある」という現象を追う場合、`const` の付いた関数は犯人候補から除外できます！

### クラス間の関係性を見抜く3段階のグラデーション

ヘッダに書かれているメンバ変数や引数の書き方を見るだけで、その関係が「命運を共にする主従関係」なのか「一時的な通りすがり」なのかが分かります。

| 表記 | 関係性の意味 | 影響度・結合度 | 寿命の連動 |
| :--- | :--- | :--- | :--- |
| `Weapon m_weapon;`<br>`std::unique_ptr<Weapon> m_weapon;` | **完全な所有（Composition）**<br>そのクラスが死ぬとこのオブジェクトも同時に消滅する。 | **最強** | 完全に一致 |
| `std::shared_ptr<Texture> m_tex;` | **共有所有（Aggregation）**<br>複数の場所で共同利用。最後の1人が手放すまで生き続ける。 | **中** | 誰かが持っていれば生存 |
| `Enemy* m_target;`<br>`const Map& m_map;` | **単なる参照・観察（Association）**<br>見るだけ。寿命管理はそのクラスの仕事ではない。 | **弱** | 相手が先に死ぬとダングリング危険 |

#### 前方宣言（`class Boss;`）を見たら「疎結合」の証
ヘッダの冒頭で `#include "Boss.h"` を書かずに、`class Boss;` とだけ書かれている場合、そのファイルは `Boss` の中身（サイズやメンバ）を知る必要がない＝**結合度が極めて低い**ことを意味します。

### 不具合調査の鉄則：「誰が値を書き換えているのか？」

テスターやデバッグ担当が追うべきは、計算式ではなく**「状態変数（フラグ・数値）の変更箇所」**です。

#### ステップ1：ターゲットのメンバ変数を特定する
例えば「敵が死なない」バグなら、`m_hp` または `m_isDead` を特定します。

#### ステップ2：セッター（Setter）を探す
クラス設計がしっかりしていれば、メンバ変数は `private` に隠蔽され、`setHp()` や `kill()` などの関数を経由して変更されます。
その関数にエディタの「参照の検索（Find All References）」をかければ、**書き換えを行っている全箇所が瞬時にリストアップ**されます！

#### ステップ3：レガシーコードでメンバが `public` だった場合の対抗策
もし `struct Enemy { int hp; bool isDead; };` のようにメンバが直接公開されていた場合、静的検索だけでは途方に暮れます。
その時は**「変数を一時的に private に書き換えてビルドする」**という裏技があります。
コンパイラが「アクセスできません」とエラーを出した場所が、**その変数を直接操作していたすべての犯人リスト**になります！

• コンパイラをデバッグツールとして使う: private化してビルドエラーを起こさせる手法は、レガシーコードの依存箇所を洗い出す現場の超強力な裏技です。

### コールスタック（Call Stack）は「現場に残された足跡」である

不具合が起きた瞬間にデバッガ（VS Code, Visual Studio, GDB, LLDB）でブレークポイントを止めると、画面の片隅に**「コールスタック（呼び出し履歴）」**が表示されます。

```
[Call Stack の表示例]
#0 Player::takeDamage(int amount=9999) <-- 今まさにここで止まっている！
#1 Bullet::onHit(Entity* other) <-- 弾が当たって呼び出した
#2 CollisionSystem::update(float dt) <-- 当たり判定システムが検知した
#3 GameManager::update(float dt) <-- メインゲームマネージャが更新した
#4 main() <-- すべての起点
```

#### コールスタックの読み方
- **下から上へ**: 時系列順の呼び出し経路（main -> update -> onHit -> takeDamage）
- **上から下へ**: 責任の所在の追跡。「なぜ 9999 という巨大なダメージが渡されたのか？」を知りたければ、スタックの `#1 Bullet::onHit` をクリックすれば、その瞬間の弾のパラメータや呼び出し元のコードへタイムスリップできます！

• 1. アルファベット順にすべての .cpp ファイルを先頭行から通読する
• 2. main() 関数や中央管理クラス（GameManager等）を特定し、全体のライフサイクルと初期化順序を把握する
• 3. すべてのヘッダファイルを1つの巨大なファイルに統合して全体検索する
• 4. すべての変数をグローバル変数に変更して挙動を観察する

正解と解説を見る

正解：main() 関数や中央管理クラス（GameManager等）を特定し、全体のライフサイクルと初期化順序を把握する
巨大なプロジェクトでは、起点（main関数、ゲームループ、中央管理クラス）から上流→下流へと流れを追うのが鉄則です。末端から順に通読するのは非効率です。

• 1. この関数を呼び出すと、オブジェクトの内部変数が必ず初期化される
• 2. この関数は内部状態を変更しない（読み取り専用）ことが保証されているため、状態変化の不具合の原因から除外しやすい
• 3. この関数は定数（const）しか引数に取ることができない
• 4. この関数はマルチスレッド環境での排他制御が自動的に行われる

正解と解説を見る

正解：この関数は内部状態を変更しない（読み取り専用）ことが保証されているため、状態変化の不具合の原因から除外しやすい
constメンバ関数は「内部状態を変更しない」という言語仕様上の制約を持つため、状態破壊のバグを追う際に調査対象から外しやすくなります。

• 1. A は B の単なる観察者であり、B の寿命には一切関与しない
• 2. B は複数のクラスで共有されており、誰が所有しているか不明である
• 3. A は B の完全な単独所有者であり、A が破棄されると B も連動して破棄される
• 4. B はコンパイル時にすべてインライン展開される

正解と解説を見る

正解：A は B の完全な単独所有者であり、A が破棄されると B も連動して破棄される
std::unique_ptr は単独所有権を表すため、所有者（A）の寿命が尽きた際に所有物（B）も自動的に解放されます。極めて強い主従関係（所有）を表します。

• 1. コンパイル速度が大幅に向上する
• 2. 現在停止している関数に至るまでの関数呼び出し経路と、各フレームでの引数の値を逆引きで追跡できる
• 3. メモリリークが自動的に検知・修正される
• 4. すべての未定義動作がコンパイルエラーとして検出される

正解と解説を見る

正解：現在停止している関数に至るまでの関数呼び出し経路と、各フレームでの引数の値を逆引きで追跡できる
コールスタックは「どの関数が、どんな引数で順に呼び出して現在地に至ったのか」という時系列の足跡を逆引きで確認できる、デバッグの最重要情報です。