背景

最近、低レイヤーやソフトウェア工学によく触れて、
デバッグの勘所が見えてきたのでメモ。

概要

• 1

  • エラーの解決方法を調べる❌
  • 中身、仕組みを見る⭕️

• 2

  • エラーはどうすれば解決する？❌
  • エラーという前提で見ない。そもそもの前提を前から順番に見る⭕️

中身、仕組みの具体例

• ORMが生成するSQL
• GUIツールでも表示される限られたエラーメッセージだけでなく、スタックトレースやエラーログを見る
• Frontend Frameworkが生成したHTML
• サーバー上のものであればログ、同じソースコードをローカルで動かした時のログ
• プリントデバッグ
• より低レイヤーを見る
• CPUでもネットワークでもwebappでも、デバッグしやすいよう層に分かれたアーキテクチャが採用されているのが基本なので、どの層で意図通り出ないか考える。

2について

そもそも、OSであれフレームワークであれ、
サーバーの設定ファイルであれ、人が限られたある動作を期待して作ったもの。
エコシステムとして取りまとめるのがうますぎて、
正解が存在するように見えるがそんなものはない。

なので今からやろうとしていることが、
どういう手順を前提としているか？それぞれのステップの期待値は？
など低レイヤー、中身の仕組みから見て考える。
そもそも公式ドキュメント以外の手順などだと、
信頼性が薄いというのはそういうこと。

公式ドキュメントの信頼性は高いが、
上記のような背景があるので間違っている可能性もあるので、
エラーや解決ばかり見るのではなく、
前から順番に確認する。データと命令しか存在しない。
しかも大抵やっていることは、ロジック実行or通信。

状態について

こういう観点も持ちたい

再現や原因判断難しいバグは、だいたい状態のせい - Qiita

結論 再現が難しかったり、原因の判断が難しいバグは、 大抵の場合状態のせい。 既存メンバーに聞くと、結構あるある問題だから、 そこまで調査せず軽く聞いてしまうのが、だいたい良い。 原因の具体例 データベースのレコード 不整合や特定の条件を持つレコードが原因でバグが発...

Qiita