体系的なデバッグ

概要

無意味な修正は時間を浪費し、新しいバグを生み出します。応急処置は根本的な問題を隠蔽するだけです。

基本原則: 修正を試みる前に、必ず根本原因を特定してください。症状に対する修正は失敗です。

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

鉄則

根本原因の調査なしに修正は行わない

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

使用すべき場合

以下のような技術的な問題には常に使用してください:

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

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

• 時間的なプレッシャーがある場合(緊急時は推測に頼りやすい)
• 「ちょっとした簡単な修正」が明らかに見える場合
• 既に複数の修正を試みた場合
• 前の修正が機能しなかった場合
• 問題を完全に理解していない場合

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

• 問題が単純に見える場合(単純なバグにも根本原因がある)
• 急いでいる場合(急ぐと必ずやり直しになる)
• マネージャーが「今すぐ修正してほしい」と言っている場合(体系的なアプローチは試行錯誤より高速)

4つのフェーズ

各フェー

...