問題が起きた時に確認すること

何か問題が起こった時に確認するポイント。

• エラーメッセージは何と出ているか
  • まず、エラーメッセージを読め。
  • エラーメッセージ自体で検索すれば大体の事象は把握できる
  • 後でナレッジとして蓄えるために、エラーメッセージはコピーして保存しておくと良い
  • スタックトレースを辿っていき、例外が発生した箇所を見てみると、原因が推測できるかもしれない
• 操作しているディレクトリ・ファイル・URL は本当に合っているか
  • 設定ファイルで dist/config/config.xml を参照する設定にしていたのに、src/config/config.xml ファイルをイジっていて、「変更が反映されない」という勘違いに時間を取られたりする
  • WLS や Wildfly 等のミドルウェアにモジュールをデプロイしているのに、変更が反映されていないように見える時は、本当にデプロイ先が正しいかよくよく確認する
  • 変更が反映されていることを確認できるよう、ログ出力や画面表示している文言などを変更して確認してみる
• 参照しているモジュールは正しいか
  • 既に修正版が本流ブランチにマージされているのに、自分の作業ブランチに取り込んでいなくてバグっていただけ、といった場合
  • package.json に記載のバージョン番号が古くてデグレードしているだけ、など
  • 依存モジュールの内容が怪しいようであれば、依存モジュールの格納場所 (node_modules/ ディレクトリなど) を「退避」しておき、再度クリーンインストールしてみる。もし再インストールによって事象が変わるようなら、「退避」しておいたモジュール群と差分を取ってみる
• ブラウザのキャッシュが残っていないか
  • 変更が反映されていないように見えたら、キャッシュをクリアしたり、スーパーリロードしたりしてみる
• 最小構成で動作させても事象が再現するか
  • 「HTTP 通信でデータを取得し、加工したデータを画面に表示する」といった処理で、画面描画が正常に行えない、といった場合に、HTTP 通信部分とデータ加工部分のメソッドを使用せず、「整形済みの固定データを直接画面に表示させる」といった最小構成にしてみて、事象が再現するか確認する
  • 正しく処理できている箇所、正しく処理できる入力データを区別していき、原因箇所を特定する
• Typo (打ち間違い・入力ミス) している箇所はないか
  • インデントに全角スペースが混ざっている、クラス名を打ち間違えている、など
  • それまで変更を入れていたファイルが、Grep して正しくヒットするか確認する
  • 大文字・小文字の違いも要チェック
• OS 環境の違いはないか
  • 開発マシンは Windows だが、本番環境は Linux である、といった場合
  • ディレクトリパスの区切り文字をバックスラッシュ \ ではなくスラッシュ / で指定しないといけなかった、といった OS の差異による不具合の可能性

複雑怪奇に見える事象ほど、「触っているファイルが違った」とか「単なるデグレだった」といったように、足元に問題があることが多い。

「きっと問題ないだろう」と推測するだけではなく、「問題がないこと」をきちんと計測・観測するべき。