درون سازوکار Unblocked برای توزیع خودکار درخواست‌های تغییر کد

یک برچسب ریسک ساده روی یک درخواست تغییر کد (PR) اکنون می‌تواند زنجیره‌ای از اصلاحات خودکار را فعال کند، پیش از آنکه مهندس انسانی حتی کد را باز کند. Unblocked در حال استقرار سیستمی است که در آن عامل‌ها (Agents) — شبیه دستیاران هوشمندی که دستورالعمل‌های دقیق را اجرا می‌کنند — نه‌تنها مشکلات را شناسایی می‌کنند، بلکه با اعمال اصلاحات مطمئن در تغییرات حساس، امتیاز ریسک را پایین می‌آورند.

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

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

موتور زمینه

این اتوماسیون توسط موتور زمینه Unblocked (Unblocked Context Engine) قدرت می‌گیرد. این موتور درکی سازمانی به عامل‌ها می‌دهد که معمولاً فقط در ذهن با‌تجربه‌ترین مهندسان تیم است. این موتور با متصل کردن و تطبیق دانش در چندین سیلو عمل می‌کند:

• کد منبع و مستندات
• گفت‌وگوها و گزارش‌های خطا (Issues)
• سیستم‌های عملیاتی (Production)

عامل‌ها از طریق MCP, CLI یا APIها به این زمینه دسترسی دارند. محصولاتی مانند Unblocked Code Review و Unblocked Code این زمینه را مستقیماً برای نوشتن و بازبینی کد به کار می‌گیرند. نتیجه، تولید نرم‌افزاری است که با توکن‌های (Tokens) — تکه‌های کوچکی از متن که مدل تکه‌تکه می‌خورد — کمتر، تکرارهای کمتر و نظارت انسانی کمتری نیاز دارد. لیا لنگفورد، مهندس ارشد نرم‌افزار در Optro، می‌گوید: «Unblocked مواردی را می‌گیرد که احتمالاً من از دست می‌دادم و واقعاً سرعت کل چرخه بازبینی را بالا می‌برد. این ابزار مسائل را زود شناسایی می‌کند، بنابراین تا زمانی که همکارانم PR را بررسی کنند، کد از قبل پاک‌تر شده است.»

چارچوب اتوماسیون سه-حلقه‌ای

رویکرد Unblocked بر سه حلقه مجزا استوار است که از اقدام ساده به سمت تکامل سیاست‌ها حرکت می‌کنند. ارزیابی ریسک بخشی از Unblocked Code Review است و با افزودن یک فایل .unblocked/risk-policies.yaml به مخزن کد فعال می‌شود.

• حلقه ۱: اقدام خودکار. عامل با استفاده از GitHub CLI، درخواست‌های تغییر کدی را که برچسب ریسک متوسط، زیاد یا بسیار زیاد دارند، پیدا می‌کند. یک دستور نمونه که در این فرآیند استفاده می‌شود به این صورت است: gh pr list --state open --search 'label:"risk: medium","risk: high","risk: highest" -is:draft'.

  مکانیزم این حلقه به صورت دقیق به این ترتیب است:
  ۱. یافتن PRهای برچسب‌دار که در ۲۴ ساعت گذشته باز شده‌اند.
  ۲. باز کردن آن‌ها در یک محیط کاری موقت (Scratch Worktree) خارج از مخزن اصلی.
  ۳. ارائه Diff و استدلال‌های مربوط به ارزیابی ریسک به عامل.
  ۴. اعمال اصلاحات مطمئن توسط عامل و نوشتن یادداشت برای مواردی که در مورد آن‌ها اطمینان ندارد.
  ۵. بازبینی Diff توسط یک انسان.
  ۶. تنها پس از تایید انسانی، تغییرات به گیت‌هاب ارسال (Push) می‌شوند.

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

• حلقه ۲: بازبینی با حضور انسان. برای جلوگیری از دشواری در تطبیق یادداشت‌ها در فایل‌های مختلف، Unblocked با Hunk (یک بازبین Diff متن‌باز برای ترمینال) ادغام شده است. Hunk یادداشت‌های عامل را مستقیماً بالای هر بخش (Hunk) از کد که مورد تحلیل قرار گرفته، نمایش می‌دهد.

  این سطح از نمایش به دو دلیل موثر است:

  • هم ارزیابی ریسک Unblocked (که توضیح می‌دهد سیاست‌ها چه چیزی را شناسایی کرده‌اند) و هم عامل تریاژ (که اصلاحیه را توضیح می‌دهد) روی یک بخش از کد روی هم قرار می‌گیرند.
  • انسان‌ها می‌توانند پاسخ دهند. بازبین می‌تواند یادداشتی مانند «اینجا به یک فلگ نیاز است، نه تست» اضافه کند، که عامل در اجرای بعدی آن را می‌خواند و پاسخ می‌دهد.

• حلقه ۳: تکامل سیاست‌ها. این یک حلقه نوظهور است که در آن عامل، خودِ سیاست ریسک را بهبود می‌بخشد. چون سیاست‌ها در یک فایل YAML ذخیره شده‌اند و نه در یک جعبه سیاه، برنامه‌ریزی‌پذیر هستند.

  به‌عنوان مثال، سیاستی برای «مهاجرت‌های پایگاه داده (تخریبی/تغییردهنده)» ممکن است به گونه‌ای تنظیم شود که اگر یک PR فایل‌های مهاجرت Flyway را تغییر دهد یا از دستورات DROP ،ALTER یا RENAME استفاده کند، ریسک آن «بسیار زیاد» تعیین شود.

  در طول آزمایش، یک عامل PRی را یافت که به دلیل داشتن ALTER TABLE ... ADD IF NOT EXISTS برچسب «ریسک بسیار زیاد» داشت. در حالی که سیاست آن را خطرناک می‌دید، عامل تشخیص داد که این تغییر افزایشی است و قابلیت بازگشت (Rollback-safe) دارد. سپس عامل یک سیاست دقیق‌تر پیشنهاد داد: «PR فایل‌های مهاجرت Flyway موجود را تغییر دهد یا حذف کند، یا مهاجرت‌هایی اضافه کند که جداول/ستون‌ها را DROP یا RENAME کنند، نوع ستون را ALTER کنند، یا ستونی NOT NULL بدون مقدار پیش‌فرض اضافه کنند.»

  عامل نام سیاست را تعیین می‌کند، معیارهای تطبیق را نقل می‌کند و متن جایگزین را در قالب یک PR برای فایل risk-policies.yaml جهت تایید انسان ارسال می‌کند.

پیاده‌سازی فنی و زمینه

سیاست‌های ریسک با تعیین یک حداقل امتیاز عمل می‌کنند. اگر یک PR چهار مورد ریسک پایین و یک مورد ریسک بسیار زیاد داشته باشد، ارزیابی نهایی «ریسک بسیار زیاد» خواهد بود؛ موارد پایین‌تر هرگز امتیاز نهایی را کاهش نمی‌دهند.

برای ساده‌سازی، Unblocked قابلیتی برای تولید سیاست ریسک ارائه می‌دهد. کاربران می‌توانند از طریق Slack، داشبورد یا اپلیکیشن مک بخواهند: «برای [namespace/repo] یک سیاست ریسک بنویس». سپس هوش مصنوعی با بررسی تاریخچه Rollbackها، مسیرهای بحرانی و حوادث قبلی مخزن، پیش‌نویس اولیه را می‌نویسد. پابل والیه، مدیر مهندسی در Clio، گزارش داده است که این فرآیند اثر ملموسی داشته: «ما از سه دور بازبینی PR به یک دور رسیدیم تا کد آماده تولید شود.»

تحلیل: تغییر پارادایم بازبینی

این تغییر، هوش مصنوعی را از یک «ابزار پیشنهاددهنده» به یک «لایه تریاژ» تبدیل می‌کند. با ایجاد یک هدف عینی و ماشین‌خوان (امتیاز ریسک)، Unblocked بازبینی کد را به یک مسئله بهینه‌سازی تبدیل کرده است که عامل‌ها می‌توانند آن را حل کنند.

برای توسعه‌دهنده، این به معنای پایان چرخه «ایرادهای جزئی» (Nitpicks) است. وقتی عامل تست‌های مفقود و تخلفات سیاستی را مدیریت می‌کند، بازبین انسانی می‌تواند روی معماری سطح بالا و منطق تمرکز کند. اثر ثانویه این است که «دانش قبیله‌ای» مهندسان ارشد در یک فایل YAML نسخه‌گذاری‌شده کدگذاری می‌شود که هوش مصنوعی به نگهداری آن کمک می‌کند.

مسیر بازبینی بدون سر (Headless Review)

در حالی که حضور انسان برای کالیبراسیون پیش‌فرض است، حلقه‌های ۱ و ۳ می‌توانند کاملاً بدون سر (Headless) اجرا شوند. چون فایل سیاست به عنوان یک اعتبارسنج نسخه‌گذاری‌شده عمل می‌کند، هدفی شفاف برای یک عامل ابری ایجاد می‌کند: برداشتن PRهای بالای یک آستانه، اعمال اصلاحات ایمن و باز کردن یک PR تکمیلی روی شاخه نویسنده.

این یک مرحله خودکار در کارخانه نرم‌افزار ایجاد می‌کند که ریسک را پیش از درخواست از انسان کاهش می‌دهد. برای اطمینان از اینکه این اتوماسیون منجر به خرابی‌های ناخواسته نشود، می‌توان ۵ لایهٔ اعتبارسنجی را برای جلوگیری از تخریب کد تولیدی توسط عامل‌های AI پیاده‌سازی کرد. وقتی تیم به عامل و اعتبارسنج اعتماد کند، می‌تواند «درها را باز کند» و اجازه دهد عامل‌ها این اصلاحات را به‌طور خودکار ادغام (Merge) کنند.

گام بعدی

تیم‌هایی که به دنبال پیاده‌سازی این سیستم هستند می‌توانند مخزن Cookbook شرکت Unblocked را برای راه‌اندازی مهارت تریاژ ریسک و اسکریپت‌های مربوطه بررسی کنند. تکامل بحرانی بعدی که باید زیر نظر گرفت، انتقال از تریاژ با کمک انسان به کاهش ریسک کاملاً خودکار در سازمان‌های مهندسی با سرعت توسعه بالا است.