دستیار کدنویسی را با یک تغییر کوچک و قابل بررسی ارزیابی کن

۱. رفتار فعلی و رفتار مورد انتظار را بنویس

قبل از درخواست تغییر، بگو مشکل با چه ورودی یا اقدامی رخ می‌دهد و نتیجه درست چیست. اگر خطایی می‌بینی، متن مرتبط آن را همراه با زمینه لازم ارائه کن. اطلاعات اتصال، کلیدها و محتوای خصوصی را از نمونه حذف کن.

یک کار کوچک انتخاب کن؛ مثلاً اصلاح اعتبارسنجی یک فرم یا توضیح مسیر اجرای یک تابع. درخواست هم‌زمان بازنویسی رابط، تغییر معماری و افزودن قابلیت، تشخیص علت خطا و بررسی نتیجه را دشوار می‌کند.

۲. مرز تغییر و زمینه پروژه را مشخص کن

فایل‌های مرتبط، زبان و ابزارهای موجود را معرفی کن. اگر بخش دیگری نباید تغییر کند، آن را صریح بنویس. از دستیار بخواه پیش از ویرایش، توضیح دهد کدام مسیر را بررسی می‌کند و چه اطلاعاتی کم است.

پیشنهاد یک پکیج یا API تازه را بدون بررسی نپذیر. نام و نسخه آن را در مستندات رسمی پیدا کن و ببین با محیط اجرای پروژه سازگار است یا نه. ساده‌بودن نمونه تولیدشده، دلیل کافی برای افزودن وابستگی تازه نیست.

مسئله: [شرح رفتار اشتباه و روش بازتولید]
رفتار درست: [نتیجه قابل بررسی]
ساختار و محدودیت‌ها: [زبان، ابزار و فایل‌های مجاز]
ابتدا مسیر مرتبط را بررسی و فرض‌هایت را اعلام کن.
کوچک‌ترین تغییر منسجم را پیشنهاد بده.
معماری، وابستگی‌ها و فایل‌های نامرتبط را تغییر نده.
در پایان بگو چه چیزی تغییر کرده و چگونه آن را بررسی کنیم.

۳. تغییر را بخوان، فقط نتیجه نهایی را نبین

Diff را مرور کن و از خودت بپرس هر تغییر چه اثری دارد. آیا یک شرط قبلی حذف شده؟ آیا مسیر خطا هنوز پیام مناسبی دارد؟ آیا کد تولیدشده اطلاعاتی را در خروجی یا Log نمایش می‌دهد که نباید نمایش داده شود؟

اگر بخشی را نمی‌فهمی، درباره همان قسمت توضیح بخواه. توضیح خوب باید با کد تطابق داشته باشد. پاسخ توصیفی دستیار را با اجرای واقعی و مستندات مقایسه کن، نه اینکه آن را شاهد صحت فرض کنی.

۴. سناریوی معمول و حالت مرزی را اجرا کن

فقط یک ورودی موفق را امتحان نکن. برای فرم، ورودی خالی و نامعتبر؛ برای فهرست، نتیجه خالی؛ و برای یک درخواست، مسیر خطا را هم بررسی کن. ابزارهای بررسی موجود پروژه، مانند TypeScript و Lint، بخشی از کنترل هستند و جای اجرای رفتار در مرورگر یا محیط مناسب را نمی‌گیرند.

تست باید نتیجه مورد انتظار را بسنجد. اگر آزمون صرفاً خط‌های همان پیاده‌سازی را تکرار کند، ممکن است با همان فرض اشتباه سبز بماند. پیش از تغییر، نمونه ورودی و خروجی درست را مستقل بنویس.

۵. نتیجه را قابل بازگشت و قابل توضیح نگه دار

تغییرهای کوچک و مشخص را جدا ثبت کن و توضیح بده چرا لازم بوده‌اند. اگر نتیجه را به هم‌تیمی تحویل می‌دهی، روش بازتولید مشکل و بررسی رفع آن را هم بنویس. فهرست «تست شد» بدون نام سناریو، برای ارزیابی کافی نیست.

دستیار کدنویسی می‌تواند سرعت بررسی و ساخت پیش‌نویس را بیشتر کند، اما مسئولیت پذیرش تغییر با تیم پروژه است. برای عملیات حساس و کدهای دسترسی یا مالی، بررسی تخصصی متناسب با همان دامنه لازم است.

چک‌لیست قدم بعدی

قبل از استفاده از نتیجه، این موارد را یک‌به‌یک مرور کن.

برای مطالعه بیشتر

این راهنما یک گردش کار پیشنهادی است. جزئیات امکانات و شرایط هر ابزار را در منبع رسمی و صفحه همان گزینه بررسی کن.

معرفی ابزارهای مرتبط در علموص

CursorReplitChatGPT