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