blast-radius

原文涵盖的主题

• Know what a change breaks
• The proof ladder
• Steps
• Hand back

Listing the callers is not the job; a search does that in a second. The job is the breakage a search does not show. A write-up that sounds right proves nothing. For each fact the change depends on, climb as far as is cheap and say where you stopped: 1. Said. Your belief. Worth nothing alone. 2. Pointed. A real file:line, in this repo or in the library's own source. 3. Walked. You followed the bad case step by step and it cannot happen. 4. Ran. A small script or test calls the real code and fails loudly if you are wrong. 5. Reproduced. You saw it in the running app. Step 4 is usually a short script that imports the same library at the same version and calls the exact function in doubt. Keep it outside the repository. 1. Read the change. What it adds, changes and deletes, and what it now does differently, including what the diff does not spell out. 2. Find the one fact. Most risky-looking changes are safe because of a single fact, such as "this only drops cache entries that are already dead". If it holds, most risks fall with it. Spend your time here. 3. Look where search stops. The library's code at the installed version. When things run: teardown, queues, timers, retries. What symb

这里只展示节选，请以完整原文和当前要求为准。