دستیار کدنویسی را با یک تغییر کوچک در پروژه بسنجید
یک ابزار ممکن است در تولید یک صفحه نمایشی موفق باشد اما هنگام تغییر پروژه موجود، قراردادهای آن را نادیده بگیرد. اگر برای کار توسعه اشتراک می‌خرید، آزمون را در یک پروژه آشنا و با یک مسئله کوچک شروع کنید. هدف، سنجش کیفیت تغییر است؛ تعداد خطوط تولیدشده معیار مناسبی نیست.
مسئله‌ای با نتیجه قابل بررسی انتخاب کنید
مثلاً یک ورودی نامعتبر که باید پیام خطا بدهد یا یک فیلتر که ترتیب نتایج را خراب می‌کند. رفتار فعلی و رفتار مورد انتظار را کوتاه بنویسید. فایل‌های مرتبط و دستور اجرای بررسی‌ها را مشخص کنید تا ابزار مجبور نباشد ساختار پروژه را حدس بزند.
محدوده تغییر را روشن کنید
از دستیار بخواهید ابتدا محل مسئله را توضیح دهد و سپس یک تغییر محدود پیشنهاد کند. تغییر نام‌های گسترده یا بازنویسی بخش‌های نامرتبط، بازبینی را سخت می‌کند. اگر ابزار برای رفع خطای ساده وابستگی تازه‌ای اضافه کرد، دلیل آن را بررسی کنید.
سه بررسی پس از دریافت کد
- رفتار: نمونه شکست قبلی اکنون درست عمل می‌کند؟
- سازگاری: نام‌گذاری و ساختار با بقیه پروژه هماهنگ است؟
- نگهداری: هم‌تیمی شما بدون توضیح طولانی می‌تواند تغییر را بفهمد؟
اجرای بررسی‌ها را خودتان تأیید کنید
ادعای موفق‌بودن تست با اجرای واقعی آن یکسان نیست. فرمان مناسب پروژه را اجرا کنید و خروجی را بخوانید. برای تغییر رابط کاربری، حالت خالی و خطا را هم ببینید. حتی یک پیشنهاد کاملاً قابل اجرا ممکن است رفتار مورد نظر شما را پیاده نکرده باشد.
تفاوت محیط و مدل
بخشی از ارزش یک دستیار به دسترسی آن به فایل‌ها، نمایش تغییرات و چرخه اجرای تست برمی‌گردد. کیفیت پاسخ مدل فقط یکی از معیارهاست. هنگام بررسی اشتراک، سقف استفاده، مدل‌های قابل دسترس و امکانات همان محیط را جداگانه بررسی کنید. ابزار مناسب باید زمان فهمیدن و بازبینی تغییر را کم کند؛ نه اینکه فقط سریع‌تر کد بنویسد.
