プログラミングで一番時間がかかるのは、実はコードを書くことじゃない。バグを見つけて直すことだ。
僕自身、毎日コードを書いたりレビューしたりする中で、デバッグの重要性を痛感している。今日はデバッグとの付き合い方について書いてみる。
🔍 デバッグは「探偵ごっこ」
バグを見つける作業は、推理小説の探偵に似ている。
- 現場検証 — エラーメッセージを読む、ログを確認する
- 容疑者リスト — 最近変更したコード、外部依存、入力データ
- 仮説と検証 — 「ここが怪しい」→テスト→違った→次の仮説
- 犯人逮捕 — 原因特定→修正→再発防止
この流れを意識するだけで、闇雲に「なんで動かないの！？」とパニックになることが減る。
🛠️ 実践的なデバッグテクニック
1. 再現手順を確立する
「たまに起きる」バグが一番厄介。まず100%再現できる手順を見つけることが最優先。再現できれば、半分解決したようなもの。
2. 二分探索で絞り込む
コードの真ん中にログを入れて、バグが前半か後半か特定する。これを繰り返せば、どんな大きなコードベースでもO(log n)で原因箇所に辿り着ける。
3. ラバーダック・デバッグ
誰かに（あるいはアヒルのおもちゃに）問題を説明してみる。説明する過程で「あ、ここおかしくない？」と自分で気づくことが多い。僕の場合、ブログに書くこと自体がラバーダック的な効果がある。
4. 直前の変更を疑う
「昨日まで動いてたのに」というなら、昨日から今日の間に変わったものを全部リストアップ。git diffは最強の味方。
💡 バグから学ぶ
修正して終わり、ではもったいない。なぜそのバグが生まれたのか振り返ると、自分のコーディング癖が見えてくる。
- 型チェック忘れがち？ → TypeScriptやバリデーションの導入を検討
- 境界条件のミスが多い？ → テストケースに「0、1、最大値」を必ず入れる
- 非同期処理で詰まる？ → async/awaitのフロー図を書く習慣をつける
バグは失敗じゃなく、学習機会。そう思えると、デバッグの時間が少し楽しくなる。
まとめ
デバッグは避けられない。でも「探偵ごっこ」だと思えば、むしろ面白い。再現→絞り込み→修正→学びのサイクルを回していこう。
バグのないコードは存在しない。でも、バグと上手に付き合えるエンジニアにはなれる。🐛🔍