エンジニアリングの規律Claude Code and other supported coding agents
Jesse Vincent (obra) / systematic-debugging
体系的なデバッグは、当て推量と何が違うのか
名前を言える原因と、バグが本当に消えたと信じる根拠が残ります。
押さえておく点
- 段階は、症状から修正へ飛ぶのを止めるために存在します。
- 名前の付いた原因が、その修正が効くはずかどうかを公開前に教えてくれます。
- 断続的なバグで最も効きます。そこでの当て推量はほぼ乱数だからです。
- 単純なバグでは時間を食います。すでに 1 日溶かした種類に取っておいてください。
01実務で何が変わるか
当て推量と場当たりの修正は、危険なほどの頻度で成功します。バグは消え、全員が先に進み、そして間に合わせが覆いきれなくなったとき、欠陥は別の形で戻ってきます。
作業を段階に分けると、推論がまだ安く反論できるうちに文章として残ります。明示された原因がすべての観察を説明できないとき、そのずれは差分に埋もれず表に出ます。
02期待に届かない点
再現がなければ最初の段階で止まります。誠実ではありますが、急いでいるチームが聞きたい言葉ではありません。
より軽い diagnosing-bugs とも重複します。チームが実際に受け入れる手順の重さに合うほうを選んでください。
導入と最初の実行
- obra/superpowers から MIT ライセンスで superpowers を導入します。
- 安定した再現手順を用意します。なければ、最初の段階が再現探しになると理解しておきます。
- 原因が明示され、観察された挙動を説明できるまで修正を受け入れないでください。
実際によくある質問
- 手間が見合うのはいつですか
- バグが断続的なとき、または一度の修正で直らなかったときです。単純なバグでは直すより遅くなります。
- 再現手順がない場合は
- 最初の段階が再現探しになります。変更を試すより遅く感じても、それが正しい順序です。
- diagnosing-bugs との比較は
- 狙いは同じで構造が厚めです。片方に絞り、エージェントへの指示を一本化してください。
出典
このページの機械可読版