体系的デバッグ

概要

無作為な修正は時間を浪費し、新しいバグを生成します。急速なパッチは根本的な問題を隠蔽します。

**コア原則:**修正を試行する前に、必ずルート原因を見つけてください。症状の修正は失敗です。

このプロセスの文字通りの違反は、デバッグの精神的な違反です。

鉄則

ルート原因調査なしに修正なし

Phase 1を完了していない場合、修正を提案することはできません。

使用時期

以下のあらゆる技術的問題に使用してください:

• テスト失敗
• 本番環境のバグ
• 予期しない動作
• パフォーマンス問題
• ビルド失敗
• インテグレーション問題

特に以下の場合に使用してください:

• 時間的プレッシャー下にある(緊急時は推測が魅力的になる)
• 「ほんの1つの簡単な修正」が明らかに見える
• 既に複数の修正を試した
• 前の修正が機能しなかった
• 問題を完全に理解していない

以下の場合はスキップしないでください:

• 問題が単純に見える(単純なバグにもルート原因がある)
• 急いでいる(急ぐと確実にやり直しになる)
• マネージャーが今すぐ修正してほしい(体系的なアプローチは試行錯誤より速い)

4段階のフェーズ

次に進む前に、各フェーズを完了する必要があります。

Pha

...