Zenn
Open2

【Debugスキル】開発・Debugスキル(問題解決・BugFixスキル)

エンジニア
debug
開発
bugfix
問題解決力
まさぴょんまさぴょん

DebugにおけるBug発生レイヤーの特定スキルについて📝

デバッグにおいてバグがどのレイヤー（層）で発生しているかを特定するスキルは、問題解決の効率化と正確性を大きく左右します。
ソフトウェアは、ハードウェア、OS、ミドルウェア、アプリケーションコード、フレームワーク、ライブラリなどの多層的な構造で動作しており、バグの原因箇所を迅速かつ正確に絞り込むことで、修正までのプロセスがスムーズになります。

バグ発生レイヤー特定のための基本的な考え方やスキルを整理します。

1. レイヤー概念と責務の理解

  • 責務の明確化:
    • 各レイヤー（例：UI層、ビジネスロジック層、データアクセス層、OS・ドライバ層など）が何を担当しているか理解しておく。
    • これにより、Bugが起きた場合、どの層が主犯になりやすいか仮説を立てやすくなる。
  • 制御フロー・データフローの把握:
    • 入力がどのように各層を通過し、どのような処理が行われ、どのように結果が出力されるかを理解することで、問題発生箇所を追跡しやすくなる。

2. 逐次的な切り分け手法

  • 二分探索的アプローチ:
    • 発生箇所をある程度上下に切り分けてテストすることで、原因を上位層か下位層かに分け、段階的に範囲を狭める。
  • ログ・トレース利用:
    • 各レイヤーでのログやトレース情報を活用し、どの段階で期待と異なる値や動作が生じているかを特定する。
  • スタブ/モック利用:
    • 下位層をモック化したり、API呼び出し部分をスタブ化したりして、上位層が正しく動作しているか単独で検証する。これにより責任分担を明確化する。

3. レイヤー毎のデバッグツール・技法

  • UIレイヤー:
    • ブラウザの開発者ツールやGUIデバッガ、要素検証ツールなどを用いてUIの問題を切り分ける。
  • ビジネスロジック層:
    • IDEのステップ実行やブレークポイント設定、ユニットテストフレームワークを用いてロジックの正当性を確認。
  • データアクセス層:
    • データベースクエリログ、ORMのデバッグモード、SQLトレースツールなどを用いてデータのやり取りに問題がないかを確認。
  • 通信・ネットワーク層:
    • パケットキャプチャツール（Wiresharkなど）やAPIゲートウェイのログで、通信異常やレスポンス不正を検証。
  • OS/ドライバ/ハードウェア層:
    • dmesgやシステムログ、特定デバイスのドライバログ、ハードウェア診断ツール等を利用する。

4. 再現性と再現条件の特定

  • 再現性確認:
    • 問題が常に発生するのか、特定条件でのみ発生するのかを明らかにする。
    • 再現条件が明確になると、対象となるレイヤーも自然と絞り込みやすい。
  • 入力条件の精査:
    • 特定の引数や設定、外部環境条件（ネットワーク負荷、メモリ圧迫状態など）でのみ問題が起きる場合、問題発生箇所を推定する手がかりとなる。

5. ドキュメンテーション・ナレッジ活用

  • 仕様書・アーキテクチャ図の参照:
    • システム全体の設計書、アーキテクチャ図を確認することで、問題が疑われるレイヤー間インターフェースを特定できる。
  • 既知の不具合・FAQの確認:
    • 過去のバグ報告やFAQ、バグトラッキングシステム(JIRA、Bugzillaなど)の履歴を参照して、類似事象がどのレイヤーで発生していたかを確認する。

6. 仮説検証的マインドセット

  • 「ここが怪しい」仮説を立てる:
    • 各レイヤーで「この入力時に異常値が生じている」「このAPI呼び出し以降で不具合が起きる」などの仮説を立て、それを裏付けるための最小限の検証を行う。
  • こまめな検証・継続的改善:
    • 一度に全層を見ようとせず、仮説を立てては検証し、却下または確定を繰り返すプロセスを回すことで、段階的に問題点を下（もしくは上）から切り落としていく。

これらのステップやツール、マインドセットを組み合わせてバグ発生レイヤーを特定していくことで、デバッグ作業を効率的かつ的確に進めることが可能になります。

まさぴょんまさぴょん

開発・Debugスキル(問題解決・BugFixスキル)

  • 開発・Debugスキル(問題解決・BugFixスキル)に関して、言語化しておく🌟

確認ポイント

  1. そもそも、どこまで正しく動いているのか？どこからおかしいのか？
    • ここまでは、正常に動いているというポイントを探す。
    • どこら辺のタイミングで、エラー挙動になっているのか？
  2. どこら辺で、Error が発生しているのか？
    • Layer や、プログラムの位置など、分析のための目星がつくといい。

Debugのための分析

  1. 正常系の動きと、現在のBugとしての動きの違いを把握する。

    • 正常系を言語的に定義する。
    • Bugの動きを言語的に定義する。

  2. どのタイミングでそのBugが発生するのか？

    • 再現条件
    • 再現手順
    • 上記を明確にする。

  3. どのLayerで、Bugとなっているのか？

    • DBに格納されている元データの問題なのか？
      • データをinsertや、updateする際の問題？
    • BackEndでのデータ加工などによる問題なのか？
    • FrontEndでのデータ加工などによる問題なのか？

Debugをしやすくするための Code上の対策

  1. 適切なエラーハンドリング
    • エラーハンドリングがない場合は、エラーハンドリングの追加など
  2. logger によるコンソール出力(標準出力)や、ファイル出力
    • FrontEndの場合は、最適なポイントで、log出力を追加するなど
    • BackEndの場合は、Loggerによるファイル出力を追加するなど