- デバッグとは何か、トラブルシューティングとは何か
- バグ (Bug) / 欠陥 (Defect) の種類と原因
- デバッグの重要性と難しさ
- 効果的なデバッギングのためのマインドセット
[[忍耐力と粘り強さ]][[体系的かつ論理的な思考]][[観察力と細部への注意]][[仮説検証の精神]][[オープンマインド (思い込みを避ける)]][[問題を切り分ける能力]]
- デバッガの基本機能
[[ブレークポイント (Breakpoints)]] (条件付きブレークポイント、ログブレークポイント)[[ステップ実行 (Stepping)]] (ステップオーバー, ステップイン, ステップアウト, ステップリターン)[[変数監視 (Watch Expressions) と値の検査・変更]][[コールスタック (Call Stack) の検査]][[式評価 (Expression Evaluation)]][[メモリダンプと検査]][[スレッドデバッグ]]
- デバッガ利用の利点 (詳細な状態確認、対話的な問題特定)
- デバッガ利用の注意点 (設定の複雑さ、パフォーマンス影響、Heisenbugの可能性)
[[各言語・IDEのデバッガ設定と起動方法]] (VS Code, IntelliJ, Visual Studioなど)
[[git diff と git log -p による変更箇所の特定]][[git blame による変更担当者と意図の追跡]][[git bisect によるバグ混入コミットの自動特定]][[ブランチやタグを活用した問題発生バージョンの特定]]
- [[問題を引き起こす最小の入力差分やコード差分を特定する自動化技法]]
- メモリリーク (Memory Leaks)
[[メモリリークの兆候と影響]][[メモリプロファイラの利用 (Valgrind (memcheck), ASan, JProfiler, VisualVM, dotMemory)]][[ヒープダンプ分析]][[ガベージコレクション (GC) ログの分析 (Java, .NETなど)]]
- ダングリングポインタ (Dangling Pointers) / 野良ポインタ (Wild Pointers) (C/C++)
- 不正メモリアクセス (Invalid Memory Access) (セグメンテーション違反など)
- バッファオーバーフロー (Buffer Overflows) / バッファオーバーリード (Buffer Overreads)
- 二重解放 (Double Free) / 解放後使用 (Use After Free)
- スタックオーバーフロー (Stack Overflow)
- メモリ破壊 (Memory Corruption)
[[メモリデバッギングツール (Valgrind, Dr. Memory, AddressSanitizer, GDB, LLDB)]]
- デッドロック (Deadlocks)
[[デッドロックの発生条件 (相互排除、保有と待機、横取り不可、循環待ち)]][[デッドロックの検出と解消 (スレッドダンプ分析、タイムアウト)]]
- レースコンディション (Race Conditions)
[[データ競合の検出ツール (ThreadSanitizer (TSan), Helgrind)]][[再現の難しさと対策 (同期機構の適切な使用)]]
- スターベーション (Starvation)
- ライブロック (Livelock)
- 非同期処理におけるコールバック地獄とデバッグ
- Promise / Future / async/await のデバッグ
[[スレッドデバッギングツールとテクニック]][[ログによるイベントシーケンスの追跡]]
- パフォーマンスボトルネックの特定
[[CPUバウンド vs. I・Oバウンド]]- プロファイリング (Profiling) MOC
[[CPUプロファイラ (サンプリング、インストルメンテーション)]][[メモリプロファイラ]] (再掲)[[I・Oプロファイラ]][[代表的なプロファイリングツール (perf, dtrace, JProfiler, YourKit, VisualVM, cProfile・profile (Python), Xdebug (PHP))]]
- フレームグラフ (Flame Graphs) の活用
- 遅いレスポンスタイムの分析
- 高いリソース使用率 (CPU、メモリ、ディスクI/O、ネットワーク) の分析
- データベースクエリの最適化 (実行計画の確認)
- アルゴリズムとデータ構造の見直し
- キャッシュ戦略の検証
- 基本的なネットワーク診断ツール
[[ping, traceroute・tracert, nslookup・dig, netstat・ss, ipconfig・ifconfig]]
- パケットキャプチャと分析 (Wireshark, tcpdump)
- HTTP関連の問題 (ステータスコード、ヘッダ、リクエスト/レスポンスボディの確認)
[[curl, Postman, ブラウザ開発者ツール]]
- API呼び出しの失敗
- ファイアウォールとプロキシ設定の確認
- DNS解決の問題
- 接続タイムアウトとレイテンシの問題
- 統合開発環境 (IDE) のデバッガ機能: (VS Code, IntelliJ IDEA, Visual Studio, Eclipse, Xcode, Android Studio) - 各IDEごとの特徴
- 言語別スタンドアロンデバッガ:
[[gdb (GNU Debugger)]], [[lldb (LLVM Debugger)]], [[pdb (Python Debugger)]], [[jdb (Java Debugger)]], [[delve (Go Debugger)]], [[WinDbg (Windows)]]
- メモリデバッガ:
[[Valgrind (Memcheck, Helgrind, Callgrind)]], [[AddressSanitizer (ASan)]], [[LeakSanitizer (LSan)]], [[ThreadSanitizer (TSan)]], [[MemorySanitizer (MSan)]]
- パフォーマンスプロファイラ:
[[perf (Linux)]], [[DTrace (Solaris, macOS, FreeBSD)]], [[Instruments (macOS)]], [[Intel VTune Profiler]], [[Java Flight Recorder (JFR) & Java Mission Control (JMC)]], [[VisualVM]], [[JProfiler]], [[YourKit (Java)]], [[cProfile・profile・Pyinstrument (Python)]], [[Xdebug・Blackfire (PHP)]]
- ネットワーク分析ツール:
[[Wireshark]], [[tcpdump]], [[Fiddler]], [[Charles Proxy]], [[mitmproxy]]
- ログ集約・分析プラットフォーム:
[[ELK Stack (Elasticsearch, Logstash, Kibana)]], [[Splunk]], [[Grafana Loki]], [[Datadog Logs]], [[Sumo Logic]]
- APM (Application Performance Monitoring) ツール:
[[Datadog]], [[New Relic]], [[Dynatrace]], [[Sentry]], [[AppDynamics]]
- リバースエンジニアリングツール:
[[IDA Pro]], [[Ghidra]], [[radare2]], [[apktool]], [[dnSpy]] (デバッグ文脈での利用)
- コード品質の向上によるバグ予防
- 効果的なエラーハンドリングと例外処理
- 効果的なロギング戦略 MOC
[[何をログに残すべきか (重要なイベント、エラー、警告、デバッグ情報)]][[ログレベルの適切な設定]][[構造化ロギングの採用]][[機密情報のログへの書き込み禁止]]
- テスト戦略によるバグ予防と早期発見
[[テスト駆動開発 (TDD) ・ ビヘイビア駆動開発 (BDD) の実践]] (再掲)[[ユニットテスト、インテグレーションテスト、システムテスト、受け入れテストの網羅]][[回帰テストの徹底]][[テスト自動化]]
- コードレビューの徹底 (バグ発見と知識共有)
- 継続的インテグレーション (CI) と継続的テスト (早期の問題検出)
- インクリメンタルな開発と頻繁なフィードバック
- 問題解決パターンの学習と適用 (例: トラブルシューティングフローチャート)
- ドキュメントの活用と作成 (既知の問題、解決策の記録)
- 静的コード解析の定期的な実施
[[やみくもな試行錯誤 (Shotgun Debugging ・ Brute-force Debugging)]][[同じ間違いの繰り返し (学習しない)]][[問題の再現を怠る ・ 再現手順が不明確]][[思い込みや先入観による原因の決めつけ]][[エラーメッセージやログを読まない・無視する]][[デバッガの機能を十分に活用しない (または全く使わない)]][[修正の検証が不十分 ・ 回帰テストをしない]][[根本原因ではなく、表面的な症状のみを修正する (パッチワーク)]][[問題を他責にする ・ 自分のコードは正しいと思い込む]][[問題を放置する ・ 隠蔽する ・ "仕様です" で済ませる]][[一度に多くの変更を加える (問題の切り分けが困難になる)]][[チームメンバーとのコミュニケーション不足]]