blast-radius

影響範囲

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

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

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

自分の説明を鵜呑みにしない

もっともらしい影響範囲の説明でも、価値はありません。正しいかどうかに関係なく、説得力があるように読めてしまいます。だから、説明をそのまま返してはいけません。全体が依存する事実を一つか二つ見つけ、コードを実行して証明してください。

どの程度確信できますか

変更の安全性が依存する事実ごとに、手間がかからない範囲で次のリストをできるだけ下まで進み、どこで止まったかを明記してください。

1. そう述べただけ。それだけでは価値がありません。
2. 該当行を示した。実際の file:line、またはライブラリ自体のソースを示します。
3. 問題のケースが発生しないことを示した。障害の過程を一つずつたどり、該当箇所に到達しないことを確認します。
4. 実行した。実際のコードを呼び出し、間違っていれば明確に失敗するスクリプトまたはテストを実行します。
5. 実行中のアプリで再現した。

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

手順

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

返す内容

• 変更内容。 明白ではない部分も含め、何が変わったか。
• 安全性の根拠となる一つの事実。 その事実を述べ、どのステップまで確認できたかを示し、証拠を提示します。証明できなかった場合は、未証明と記載します。
• リスク。 それぞれについて、どのように壊れるか、file:line、発生可能性と深刻度、確認方法を示します。重要なリスクについては証拠を貼り付けます。
• 問題なしと確認した項目。 確認した内容と問題ないと判断した理由。
• マージ前に行うこと。 実際の不具合を検出できる、最も手軽なテストまたは再現方法を、作成したスクリプトとともに示します。

unslop を通して記述し、実際のコードを引用し、公開する前に機密情報をすべて取り除いてください。

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