ارزیاب ریسک بازسازی کد: کد شلخته را به یک برنامه پاکسازی اولویت‌بندی‌شده تبدیل کنید
چرا این پرامپت اهمیت دارد
Refactoring proposals get rejected or turn into open-ended rewrites for the same reason: without a risk/effort breakdown, “we should clean this up” sounds like unbounded work with no clear payoff, so teams either approve a full rewrite that stalls for months or reject cleanup entirely and let the next incident happen in the same code.
ما از آن برای چه استفاده می‌کنیم
A senior engineer inherits a payment webhook handler that has caused three production incidents in the last quarter and needs to convince a skeptical team lead to allocate cleanup time instead of just adding another patch.
پرامپت
Act as a senior software engineer conducting a pre-refactor risk assessment — the kind you'd do before asking a team lead to allocate sprint time to cleanup work, not a casual code review. Context: Language/framework: [LANGUAGE OR FRAMEWORK, e.g., "Python/Django"]. Here is the code with known problems: [PASTE YOUR CODE HERE]. Why I want to refactor it: [REASON, e.g., "every feature added to this file causes a regression elsewhere" or "onboarding a new engineer here takes two weeks instead of two days"]. Hard constraints I'm working under: [CONSTRAINTS, e.g., "cannot change the public API," "must ship in small increments," "test coverage on this file is under 20%"]. Task: Identify every distinct problem in the code (not just the obvious one). For each problem, assess: (a) the risk of leaving it as-is, specifically what breaks and under what conditions, (b) the effort to fix it, in rough size terms (small/medium/large), and (c) whether it's safe to fix without new tests first. Then produce concrete before/after code examples for the two or three highest-priority problems. Finally, group everything into a phased plan ordered by risk-reduction-per-unit-effort, not by what's most satisfying to fix first. Constraints: - Do not recommend a full rewrite unless you can name the specific problem that makes incremental fixes impossible. Default assumption is that incremental fixes are possible. - Every phase must be independently shippable — no phase should depend on a later phase being finished first. - If a fix requires test coverage that doesn't exist yet, say so explicitly and put "write tests for X" as its own line item before the fix, not bundled into it. - Do not flag stylistic preferences (naming, formatting) as risk items unless they're actively causing the stated problem. Output Format: 1. A table: Problem | Risk if left unaddressed | Fix effort (S/M/L) | Needs new tests first? (Y/N) 2. Before/after code blocks for the top 2-3 priority items, each with a one-line explanation of what changed and why it's safe 3. A phased plan: Phase 1 (ship this week), Phase 2 (ship this sprint), Phase 3 (needs test coverage or design discussion first)
نتیجه
Context provided: A 40-line Python function in a Django app that validates and processes incoming webhook payloads from a payment provider. Reason for refactor: "every time we add a new payment event type, someone breaks the refund flow." Constraint: "can't change the public webhook URL or the response format the payment provider expects."
1. Risk/Effort Table
| Problem | Risk if left unaddressed | Fix effort | Needs tests first? |
|---|---|---|---|
| Event type dispatch is a 15-branch if/elif chain | New event types get inserted in the wrong branch order; refund logic silently skipped for event types added after it | M | Y |
| Signature verification and business logic are in the same function | Cannot unit test business logic without mocking HTTP signature headers | S | N |
| Refund amount is recalculated in three places with slightly different rounding | Silent off-by-cents discrepancies on high-volume days | S | Y |
| No idempotency check on webhook retries | Duplicate refunds if the payment provider retries a slow response | M | Y |
2. Before/After — Priority 1 (dispatch chain)
Before: if event_type == "charge.success": ... elif event_type == "refund.issued": ... elif event_type == "charge.failed": ... (15 branches, refund logic on branch 11)
After: HANDLERS = {"charge.success": handle_charge, "refund.issued": handle_refund, ...}; HANDLERS.get(event_type, handle_unknown)(payload) — safe because new event types now require an explicit registry entry instead of falling through an unrelated elif chain, and missing handlers fail loudly instead of silently matching the wrong branch.
3. Phased Plan
Phase 1 (this week): Extract signature verification into its own function (S, no tests needed — pure extraction, behavior unchanged). Write unit tests for the current dispatch behavior before touching it.
Phase 2 (this sprint): Replace the if/elif chain with the handler registry, using the Phase 1 tests as a safety net. Consolidate the three refund rounding implementations into one function.
Phase 3 (needs design discussion): Add idempotency keys — this touches the database schema (a new "processed_webhook_ids" table) and needs a decision on retention period, so it's not a pure refactor.
پیشنهادهای بازسازی کد به دلیلی قابل پیش‌بینی رد می‌شوند: به‌صورت یک احساس («این کد بد است») می‌آیند، نه یک برنامه (چه چیزی ریسک دارد، رفع چه چیزی ارزان است، به چه ترتیبی باید رفع شود). یک رهبر تیم که با یک درخواست پاکسازی مبهم روبرو می‌شود دو گزینه دارد — تأیید یک بازنویسی نامحدود که خط پایان مشخصی ندارد، یا رد آن و اجازه دادن به مشکل زیربنایی که حادثه بعدی را ایجاد کند.
چرا این پرامپت ریسک را از تلاش جدا می‌کند
این پرامپت دو قضاوت مستقل برای هر مشکل را الزامی می‌کند — چقدر بد است اگر کاری نکنیم، و رفع آن چقدر هزینه دارد — به‌جای یک امتیاز «اولویت» ترکیبی. برخی از ترسناک‌ترین کدها (یک زنجیره ۱۵ شاخه‌ای که یک حالت شکست خاموش را پنهان می‌کند) ارزان برای رفع هستند.
چرا هر مرحله باید به‌طور مستقل قابل ارسال باشد
محدودیتی که هیچ مرحله‌ای نباید به اتمام مرحله بعدی وابسته باشد به این دلیل است که تلاش‌های بازسازی در فاصله بین «شروع‌شده» و «تمام‌شده» می‌میرند.
چرا این پرامپت به‌طور پیش‌فرض بازنویسی پیشنهاد نمی‌دهد
بازنویسی کامل معادل بازسازی برای پیشنهاد قطع عضو توسط پزشک برای پیچ‌خوردگی مچ پا است — گاهی درست، معمولاً نه.
چرا «نیاز به تست دارد» یک ستون جداگانه است، نه یک پانویس
رایج‌ترین راهی که بازسازی اشتباه می‌شود، قضاوت بد درباره چیزی که باید رفع شود نیست — رفع چیزی است که به‌درستی به‌عنوان پرخطر شناسایی شده بدون یک شبکه ایمنی برای گرفتن رگرسیون.
چگونه این را برای پایگاه کد خود تطبیق دهید
این پرامپت روی یک تابع منفرد یا یک ماژول کامل کار می‌کند — برای دامنه‌های بزرگ‌تر، انتظار داشته باشید جدول ریسک/تلاش طولانی‌تر شود.