رفتن به محتوا
AI Forwardپیشرفت سازمان با هوش مصنوعی
خانهپروژه‌های بهبودتوسعه و نگهداری

کمک به برنامه‌نویسی در تغییرهای محدود

P19

فنی

برنامه شروع

تغییر محدود کد با آزمون معتبر و بازبینی روشن، سریع‌تر به تحویل برسد.

قدم اول

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

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

ورودی‌های لازم

  • کد و نسخه محصول
  • کار محدود با نتیجه مورد انتظار
  • دستور آزمون و بازبین

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

روش آزمون و ابزارها

مقایسه با روش فعلی

همان توسعه‌دهنده با شرح کار P03، جست‌وجوی منبع، ابزار ویرایش، lint و آزمون محلی کار هم‌سطح انجام می‌دهد؛ زمان خواندن، بازبینی و اصلاح هم حساب شود.

نمونه آزمون

پیشنهاد: ۱۰ کار کوچک در پنج جفت هم‌سطح، بدون پرداخت یا مجوز تولید؛ ترتیب روش‌ها عوض شود تا اثر یادگیری کمتر شود. یک کار برای تنظیم ابزار خارج از مجموعه ارزیابی باشد؛ در صورت پراکندگی زیاد، نتیجه نامشخص و نمونه بزرگ‌تر لازم است.

  • زمان فعال تا diff پذیرفته‌شده شامل خواندن و تصحیح خروجی و بازبینی
  • نرخ پذیرش بار اول، تعداد دور اصلاح و نقص مرتبط کشف‌شده در آزمون مستقل
  • تغییر خارج از محدوده، وابستگی غیرضروری و مورد افشای کد یا داده
  • هزینه کل هر کار پذیرفته‌شده با نسخه مدل ثابت؛ پیام تولیدشده یا خط کد معیار بهره‌وری نیست

معیار پیشنهادی پذیرش

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

ابزارهای مرتبط

  • Aider — دستیار diff محدود
  • Playwright — آزمون مستقل رفتار وب

منابع فنی

منابع این پیشنهاد: RS01 · RS11 · RS12 · RS30 · RS32

جزئیات پروژه و منابع
محصول / سامانه هدف

همه محصولات

زمان کاری برآوردشده برای آزمون اولیه

۱–۳ هفته کار یک نفر

نقش پاسخ‌گو

مسئول فنی هر محصول

پیش‌نویس کار

این پروژه چه کمکی به کار روزانه می‌کند؟

یک مثال فرضی: برنامه‌نویس می‌خواهد خطای پذیرفته‌نشدن شماره معتبر را رفع کند. دستیار محل مرتبط را پیدا و یک اصلاح محدود پیشنهاد می‌کند.

برای شروع، چه چیزی آماده می‌شود؟

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

در مرحله بعد، چه می‌توان اضافه کرد؟

خطاهای تکراری و روش حلشان در راهنمای پروژه ثبت می‌شوند تا اصلاح‌های بعدی سریع‌تر شوند.

برنامه‌نویس تغییر را بررسی می‌کند؛ اصلاح یک خطا مجوز تغییر بی‌ربط بخش‌های دیگر نیست.

مراحل پیشنهادی کار

  1. مرحله ۱

    کار و کد مرتبط

    کار، نتیجه مورد انتظار، کد مرتبط و قالب ورودی و خروجی را مشخص می‌کنیم.

  2. مرحله ۲

    پیشنهاد تغییر کوچک

    مدل راه‌حل یا تغییر کوچکی در کد پیشنهاد می‌دهد.

  3. مرحله ۳

    بازبینی توسعه‌دهنده

    برنامه‌نویس تغییرها و اثر آن‌ها بر بخش‌های مرتبط را بازبینی می‌کند.

  4. مرحله ۴

    آزمون محلی

    آزمون متناسب با تغییر را در محیط محلی اجرا می‌کنیم.

  5. مرحله ۵

    پیوست نتیجه آزمون به کار ثبت‌شده

    گزارش آزمون به همان کار پیوست می‌شود؛ انتشار فقط با روال و مجوز فعلی انجام می‌شود.

زمان، درستی خروجی و فایده کار را بسنجیم

۱. زمان و هزینه انجام کار

زمان فعال تا تفاوت نسخه قبل و بعد پذیرفته شده، شامل بازبینی

۲. کیفیت و اعتبار

باگ برگشتی/امنیتی و نرخ بازکاری

۳. فایده و نتیجه اقتصادی

زمان تحویل قابلیت اثرگذار بر مشتری؛ نسبت دادن درآمد نیازمند آزمایش

توضیحات بیشتر برای اجرا و بررسی نتیجه

این کار کجا ثبت می‌شود؟

همان کار تیمیک و تفاوت نسخه قبل و بعد مخزن؛ قوانین main-only و ممنوعیت GitHub Actions رعایت شوند

هر مرحله را چه کسی انجام می‌دهد و به چه کسی تحویل می‌دهد؟
هر فرد چه کاری انجام می‌دهد؟
  1. ۱

    درخواست‌کننده، تغییر لازم را توضیح می‌دهد

  2. ۲

    برنامه‌نویس مسئول، تغییر را انجام می‌دهد

  3. ۳

    بازبین انسانی

تغییر قرارداد SSO/پرداخت نیازمند بازبین حوزه است.

درخواست‌کننده ← برنامه‌نویس مسئول، تغییر را انجام می‌دهد ← بازبین، کد را بررسی می‌کند؛ تغییر ورود یکپارچه یا پرداخت به تأیید کارشناس همان بخش نیاز دارد.

از کجا بفهمیم آزمون اولیه موفق بوده است؟

۱۰ کار هم‌سطح با روش فعلی برای مقایسه؛ زمان خواندن و اصلاح خروجی مدل هم حساب شود؛ تست معنادار و بازبین مشخص.

چه زمانی باید کار را متوقف کنیم؟
شرط توقف در این پروژه

عدم موفقیت با تعویض پنهان مدل/ارائه‌دهنده یا تضعیف تست پوشانده نشود؛ push/deploy/migration مجوز جدا دارند.

ابزارها و منابع 6 مورد توضیح مفاهیم این حوزه
برای شروع چه لازم است و بعد چه می‌کنیم؟

چه چیزهایی باید آماده باشد؟

این موارد باید از پروژه‌های مرتبط آماده شوند؛ کامل‌شدن همه امکانات آن پروژه‌ها لازم نیست.

  • P03؛ دیدن پروژه مرتبط

    برای هر کار، مسئله، مسئول، موعد و نشانه تحویل درست نوشته شود؛ مثلاً «فرم با شماره آزمون ثبت‌نام را کامل کند».

  • P20؛ دیدن پروژه مرتبط

    مسیرهای مهم کاربر و حساب‌ها و داده‌های آزمایشی آماده باشند؛ مثلاً خرید با پرداخت آزمایشی.

مراحل پیشنهادی اجرا و توسعه

این مراحل برنامه پیشنهادی‌اند؛ انجام‌شدن آن‌ها هنوز تأیید نشده است.

  1. مرحله ۱فهم خطا

    محل کد و علت احتمالی را با شاهد مشخص کنید.

  2. مرحله ۲اصلاح کوچک

    فقط بخش لازم را تغییر دهید و تغییر را برای بازبینی نشان دهید.

  3. مرحله ۳آزمون و ثبت

    نمونه خراب و سالم را آزمایش و روش رفع خطا را مستند کنید.