‏۱۰ ترفند برای مهار کدهای شلوغ AI تو پروژه‌های فرانت‌اند

طبق این پست، حالا یه «نفر» می‌تونه تو یه هفته به اندازه‌ی یه تیم کامل کد بنویسه، ولی این هم‌نویسنده‌ی جدید نه چیزی که دیروز توافق شده رو یادشه، نه جواب‌گوی پروداکشنه، نه شش ماه دیگه هست که تصمیماتشو توضیح بده. مسئولیت هنوز رو دوش تیمه، فقط حالا کدبیس چند برابر سریع‌تر رشد می‌کنه. نویسنده ده تا چک معرفی می‌کنه که تو سه دسته جا می‌گیرن: جلوگیری از نوشتن کد اضافه، پیدا کردن کد اضافه‌ای که نوشته شده، و اجباری کردن همه‌ی این چک‌ها تو CI.

اولین راه، قرارداد API ـه. یکی از رایج‌ترین باگ‌های کد AI اینه که یه فیلد ناموجود رو حدس می‌زنه - مثلاً می‌نویسه user.fullName در حالی که بک‌اند firstName و lastName می‌فرسته. با تولید type ها و کلاینت و schema های Zod مستقیم از spec، همچین کدی اصلاً کامپایل نمی‌شه. کنارش، فعال کردن strict: true و پرچم‌هایی مثل noUncheckedIndexedAccess تو TypeScript جلوی خیلی از حدس‌های بی‌جای مدل رو می‌گیره.

لینترها هم به‌جای سند سبک نوشتاری، فیلتر رفتاری می‌شن: sonarjs پیچیدگی و تکرار رو می‌گیره، یه پلاگین مخصوص جلوی effect های غیرضروری رو می‌گیره (رایج‌ترین اصلاحی که نویسنده رو کد AI دیده)، و پلاگین‌های تست جلوی تستِ بدون assertion یا .only فراموش‌شده رو می‌گیرن. کنارش، ابزارهایی مثل eslint-plugin-boundaries مرز بین لایه‌های اپ (کامپوننت، سرویس، دیزاین سیستم) رو مشخص می‌کنن تا مدل معماری پروژه رو یادش نره و کدبیس به‌سمت الگوهای رایج گیت‌هاب کج نشه.

برای تست خود تست‌ها، Stryker با تغییر عمدی کد (مثل برعکس کردن یه شرط) نشون می‌ده کدوم تست‌ها اصلاً متوجه خراب شدن کد نمی‌شن. برای کد مرده و تکراری هم Knip و jscpd به کار میان؛ نویسنده حتی یه اسکریپت کوچیک نوشته که چک می‌کنه یه vi.mock() هنوز با export های واقعی ماژول همخونی داره یا نه:

const target = resolveModule(specifier, specPath);
const real = exportsOf(target);
const missing = keys.filter((key) => !real.has(key));
if (missing.length > 0) {
  findings.push({ file, line, specifier, reason: `not exported: ${missing}` });
}

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

نکات کلیدی:

• قرارداد OpenAPI + Zod جلوی فیلدهای ناموجود (مثل user.fullName به‌جای firstName/lastName) رو تو کامپایل می‌گیره
• لینترهای رفتاری (sonarjs، ردیاب effect غیرضروری، پلاگین تست) و eslint-plugin-boundaries جلوی معماری کج‌شده و تست‌های بی‌اثر رو می‌گیرن
• Stryker با جهش عمدی کد نشون می‌ده کدوم تست‌ها واقعاً چیزی رو چک می‌کنن؛ Knip و jscpd کد مرده و تکراری رو پیدا می‌کنن
• رول‌اوت باید تدریجی باشه: اول warning رو کد تغییریافته، بعد error برای قانون‌های مفید، و گیت CI در آخر