99. 原因の切り分け — 範囲を半分にしていく型

バグ調査の基本は、どこが壊れたかの範囲をひたすら狭めることです。代表的な手法が二分探索で、怪しい範囲の半分をコメントアウトして症状が消えるか試します。消えればコメントアウトした側に、残ればもう半分に原因があります。これを繰り返せば、数十行の候補でも数回の試行で1行まで絞り込めます。

「さっきまで動いていた」なら、動いていた状態との差分が最大の手がかりです。git diff で直前のコミットからの変更点を一覧すれば、原因はほぼ必ずその中にあります。また、バグの箇所だけを小さな新しいコンポーネントに移して再現する「最小再現」を作ると、無関係な要素が消えて原因が浮かび上がります。

手当たり次第に直そうとするのは逆効果です。疑う順番の型を持ちましょう。まずデータ(APIの応答は正しいか)、次にロジック(加工後の値は正しいか)、最後に表示(テンプレートの書き方は正しいか)の順に、各段階で値を実際に確認してから次へ進みます。そして一度に変えるのは一箇所だけ、が鉄則です。

サンプルコード(フレームワーク環境が必要なため表示のみ)

// 切り分けの型 ① 二分探索(半分コメントアウト)
//
// 「このページを開くとエラーになる」→ テンプレートの半分を消して試す
//   前半だけ残す → エラー消えた → 原因は後半にある
//   後半をさらに半分に → …数回で1行まで絞れる
//
// 切り分けの型 ② 動いていた状態との差分
//   git diff              # 直前のコミットからの変更を一覧
//   git stash             # 変更を一時退避して「動く状態」に戻して確認
//   git stash pop         # 退避した変更を戻す
//
// 切り分けの型 ③ どの層で壊れたかを順に疑う
//
//   [データ]   APIの応答は正しいか   → Network タブで確認
//      ↓ 正しい
//   [ロジック] 加工後の値は正しいか → ブレークポイントで確認
//      ↓ 正しい
//   [表示]     テンプレートは正しいか → Angular DevTools で確認
//
// 鉄則: 一度に変えるのは一箇所だけ。
// 二箇所同時に変えると、直っても壊れても原因が特定できない

サンプルコードで身につける(5本) →

学んだ概念を、素朴な例から実務寄りの例まで5つの具体例で確認します。

公式ドキュメントで詳しく ↗