blast-radius

影響範囲

変更をリリースする前に、別の場所で何が壊れるかを見つけます。「X の影響範囲」「これで何が壊れる可能性があるか」や、まだ信頼できない小さな差分のレビューに使います。

how と why を補完します。how はコードが何をするかを説明します。why は、なぜそのような形になっているかを説明します。影響範囲では、別の場所で何が壊れるかを説明します。

呼び出し元を列挙することが仕事ではありません。エージェントなら、2つ目の手順で grep できます。仕事は、grep では見つからない不具合を見つけることです。

自分の説明を信じない

もっともらしく聞こえる影響範囲の説明には価値がありません。それが真実かどうかにかかわらず、説得力があるように読めてしまいます。だから、説明をそのまま返してはいけません。全体が依存する1つか2つの事実を見つけ、コードを実行して証明してください。

どの程度確信がありますか

変更の安全性が依存する事実ごとに、無理のない範囲で以下のリストをできるだけ下まで進み、どこで止まったかを伝えてください。

1. そう言った。単独では価値がありません。
2. 該当行を示した。実際の file:line、またはライブラリ自体のソースです。
3. 問題が起きるケースがないことを示した。失敗までの手順を追い、そこに至らないことを確認しました。
4. 実行した。実際のコードを呼び出し、誤りがあれば明確に失敗するスクリプトまたはテストです。
5. 実行中のアプリで再現した。

手順4では通常、アプリが実際に使っているものと同じライブラリをインポートし、懸念している関数を正確に呼び出す小さなスクリプトを使います。

手順

1. 変更を読みます。差分、追加・変更・削除されたシンボル、そして差分に明記されていない部分も含め、これまでと何が異なるかを確認します。PR とコミットを取得するには、why の手順2を使います。
2. 安全性を支える1つの事実を見つけます。リスクがあるように見える変更の多くは、「この呼び出しは、すでに無効になったキャッシュエントリを削除するだけで、ほかのことは何もしない」のような、1つの事実によって安全です。その事実を見つけてください。それが成り立てば、リスクがあるように見えるケースの大半は一度に解消できます。あれこれ可能性を並べるのではなく、ここに時間を使ってください。
3. grep で追えなくなる場所を調べます。呼び出しているライブラリのソースを読み、固定されたバージョンとローカルのパッチを確認します。処理がいつ実行されるかを把握してください。マイクロタスク、アンマウントとティアダウン、Solid と React の違いなどです。シンボル検索では見つからないものを追います。API が返す JSON、DB のカラム、ワイヤ形式、同じバイト列を読み取る別の言語、フィーチャーフラグ、3段階先にあるコードなどです。
4. 各リスクについて正直に評価します。実際に起こる可能性と、起きた場合の実害を示してください。確認できたリスクを残します。確認して解消したものは、別に列挙します。why と同じルールに従ってください。実際の file:line を引用し、何も見つからない検索も答えとして示します。呼び出し元や API を捏造してはいけません。
5. 1つの事実を証明します。実際のコードを実行するスクリプトまたはテストを書いて実行し、結果を貼り付けます。
6. 大規模または広範囲に及ぶ変更では、arena として実行します。複数のモデルに同じ質問をして、回答を統合します。モデルによって、異なる実際のバグが見つかります。

返す内容

• 何をするか。 変更内容を、明白でない部分も含めて説明します。
• 安全性を支える1つの事実。 その事実を述べ、どの手順まで確認したかを示し、証拠を提示します。証明できなかった場合は、未証明と記載します。
• リスク。 それぞれについて、どのように壊れるか、file:line、発生可能性と影響の大きさ、確認方法を示します。重要なものは証拠を貼り付けます。
• 解消済み。 確認した内容と、問題ない理由を示します。
• マージ前に。 実際のバグを検出できる、もっとも手軽なテストまたは再現方法を示します。作成したスクリプトも含めます。

unslop を使って作成し、実際のコードを引用し、公開する前に非公開情報をすべて削除してください。

返信： 上記の説明を返します。安全性を支える1つの事実は、証明済みとするか、未証明と明記してください。