※本記事は広告を含みます。
デバッグ技術シリーズ
デバッグ技術についてまとめたシリーズです。
- 組み込みエンジニアが知っておきたいデバッグの基本的な進め方（この記事）
- 組み込みエンジニアが新人時代にやりがちなデバッグの無駄7選
組み込みソフトの開発で、デバッグに何時間も溶けた経験はないでしょうか。
・原因が分からない
・ログを眺め続ける
・気づいたら1日終わっている
私も新人の頃、同じことを何度も繰り返していました。
今振り返ると、デバッグが遅かった理由は「能力」ではなくやり方の問題でした。
この記事では、私が新人時代に実際にやってしまっていた
無駄なデバッグ作業をまとめます。
同じ失敗を減らすヒントになれば嬉しいです。
デバッグは「センス」ではなく「手順」
新人の頃はこう思っていました。
「デバッグが速い人は頭がいい」
「自分は向いていないのかも」
でも違いました。
デバッグが速い人は
正しい順番で調べているだけ。
逆に言うと、順番を間違えると永遠に沼ります。
新人時代にやっていたデバッグの無駄7選についてまとめました。
① いきなりコードを読み始める
再現した瞬間にソースを開いていませんか？
これは典型的な失敗です。
コードを読む前にやるべきことは
現象を固定すること。
再現条件が曖昧なままコードを読んでも、
原因はほぼ見つかりません。
② 再現手順を固定しない
毎回違う操作で再現させていると、
原因の切り分けが不可能になります。
デバッグの第一歩はこれです。
- 何をすると
- 何秒後に
- どんな状態で
必ず同じ現象が出る状態を作る。
これだけで難易度が一気に下がります。
③ 直近の変更を確認しない
バグの多くはここにあります。
- 直近で変更した箇所
- 関連機能の修正
- 設定変更
新人時代の私は、
過去全体から探していました。
本当はまず
「最近変わったところ」から。
④ 仮説を立てずに調査する
ログを見る → 思いつきで修正 → 動かす
このループ、危険です。
デバッグは推理です。
必ず先に仮説を立てる。
例：
- タイミング問題？
- 初期化漏れ？
- メモリ破壊？
仮説があるだけで調査が一直線になります。
⑤ ログを追加するのをためらう
新人の頃は「ログ増やしていいのかな」と遠慮していました。
でもデバッグ中は別。
ログは武器です。
・変数の値
・処理の通過点
・分岐結果
見えないものは解決できません。
⑥ 影響範囲を考えない
1箇所だけ見続けて沼る。
でもバグは連鎖します。
- タスク間通信
- 割り込み
- 状態遷移
システム全体で見る視点が重要。
⑦ 一人で抱え込む
一番大きな失敗がこれ。
30分悩んでも進まないなら
先輩に聞く方が速い。
説明する過程で気付くことも多いです。
デバッグを速くする基本の流れ
今はこの順番で進めています。
- 再現条件を固定
- 直近変更を確認
- 仮説を立てる
- ログ追加
- 範囲を絞る
- 原因特定
この手順だけで、デバッグ時間は大きく変わります。
まとめ
新人時代、デバッグが遅かったのは
能力ではなく「順番」の問題でした。
同じように悩んでいる方の参考になれば嬉しいです。
この記事が参考になった方へ
組み込みエンジニアの技術についてまとめています。
- 組み込みエンジニアが知っておきたいデバッグの基本的な進め方
- 組み込みエンジニアが新人時代にやりがちなデバッグの無駄7選（この記事）
- 組み込み開発でmallocが嫌われる理由 ― メモリ構造とリアルタイム性から考える設計判断 ―
技術に関するご相談・開発・自動化ツール作成・記事執筆などのご依頼も承っています。
小さなご相談からでもお気軽にご連絡ください。
コメント