debug

根本原因を把握する前に、バグを修正してはいけません。調査は症状から始めますが、症状だけで終わらせてはいけません。

最短手順：エラー出力に最初の原因が直接示されている場合は、仮説の手順を省略します。原因を示すスタック行などがその例です。ただし、再現、回帰テスト、手順 8 の verify スキルは省略しないでください。見えている修正を適用しても、最初の試行で再現が解消されなければ、原因は見えていなかったということです。その場合は、すべての手順を実行してください。

1. バグを再現する前に、以下の手順を項目とするタスクリストを作成してください。すでにタスクリストがある場合は、そこに手順を追加してください。各手順を 1 つの項目にします。手順を省略する場合は、完了済みとしてマークし、項目のテキストに skip: <reason> を追加してください。最短手順では、この方法で仮説の手順を省略します。前の手順に戻る場合は、その手順とそれ以降の各手順を新しい項目として再度追加してください。その後、新しい項目に置き換えられた未完了の項目を削除してください。
2. まずバグを再現してください。毎回失敗する最小の再現ケースを作成します。バグを再現できない場合は、再現できるまでログ、入力、バージョンなどの証拠を集めてください。推測してはいけません。
3. 実際のエラーを読みます。最も近い症状ではなく、原因の連鎖における最初の原因を見つけてください。
4. 仮説を 1 つ立てます。それを裏付ける、または否定する観察結果とともに記述してください。修正に着手する前に、その観察結果を得てください。ログ行、アサーション、プローブなどが該当します。必要な証拠がまだない場合は、計測を追加してください。計測は小さく、簡単に削除できるものにし、答えが得られたら削除してください。
5. 2 つの仮説が競合する場合、どちらが正しいかを示す観察方法を 1 つ設計してください。修正を次々に試してはいけません。
6. 根本原因を、1 回に 1 つの修正で解消してください。2 つ目のバグなど、見つけた別の問題には印を付けますが、修正してはいけません。デッドコードは別の問題ではありません。修正前に、修正対象の各ファイルからデッドコードを削除してください。これは implement が行うのと同じです。バグがそのコードに関係していなかった場合も同様です。デッドコードとは、呼び出し元がない関数、インポート、パラメーター、および呼び出し元から到達できない分岐です。また、古くなったフラグや、境界ですでに行われたチェックを繰り返すバリデーターも含まれます。コードの内容を言い換えたり、回避策を正当化したりするコメントも含まれます。対象外とする事項によって範囲外に置かれたデッドコードは残してください。ガード、キャッチ、または修正を擁護するコメントを追加する修正の前に、根本原因の修正を読んでください。同じ原因がほかの場所でも発生しうる場合や、再起動後にのみ失敗が現れる場合も、同資料を読んでください。
7. このバグを検出できたはずの回帰テストを追加してください。古いコードでは失敗し、修正後は成功するテストです。
8. 修正を報告する前に、verify スキルを読み、その指示に従ってください。報告ではバグが修正されたと主張し、verify によってその主張を証明します。バグがスライス内で発生した場合、スライスのコミットが完了するまで、完全なゲートの実行を待ちます。

ルール：

• 効果があるかどうかを確かめるために、いくつもの修正を手当たり次第に試してはいけません。
• 仮説が 3 回連続で否定されたら、調査を終了してください。入手可能な証拠では再現できない場合も終了します。その場合は、試したことと不足している観察結果を報告し、判断をユーザーに委ねてください。
• 修正によって再現が解消されない場合、仮説は誤りです。手順 4 に戻ってください。失敗した修正を残したまま、2 つ目の修正を追加してはいけません。2 つの失敗した修正が同じ前提を共有していた場合は、前提を検証するを読んでください。
• 根本原因が設計上の問題を示している場合は、そのことを伝えてください。再設計について drill を実行することを提案してください。回避策で問題を隠してはいけません。
• 原因の特定に複数の仮説が必要だった場合は、その原因を即座に示せたはずの、低コストで常時有効なシグナルを提案してください。これはログ行、メトリクス、またはアサーションです。ユーザーの同意を得てから追加してください。