بازبینی Pull Request با هوش مصنوعی: ۸ گیت برای حفظ تصمیم انسانی

بازبینی کد با هوش مصنوعی می‌تواند الگوهای تکراری، خطاهای محتمل و نقاط مبهم یک Pull Request را زودتر جلوی چشم تیم بگذارد؛ اما سرعت کشف با صلاحیت تصمیم یکی نیست. وقتی یک ابزار AI می‌گوید تغییر «آماده تأیید» است، هنوز کسی باید مسئول این پاسخ باشد که آیا نیاز کسب‌وکار درست فهمیده شده، تست‌ها کافی‌اند، داده حساس در خطر نیست و تغییر تازه‌ای پس از Review وارد نشده است.

این موضوع اکنون عملی‌تر شده است. طبق اعلام رسمی GitHub در اول سپتامبر ۲۰۲۶، Copilot Code Review می‌تواند در صورت فعال‌سازی مدیریتی یک Approval ثبت کند که در قواعد Required Approval حساب شود. قابلیت به‌صورت پیش‌فرض خاموش و در Public Preview معرفی شده است. بنابراین پرسش خوب برای تیم‌ها «AI را روشن کنیم یا نه؟» نیست؛ پرسش بهتر این است: «چه معماری کنترلی اجازه می‌دهد از AI استفاده کنیم، بدون آن‌که مرز مسئولیت محو شود؟»

اصل پایه: AI یک سیگنال است، نه مالک تصمیم

Review ماشینی باید در کنار سیگنال‌های دیگر قرار بگیرد: نتیجه CI، تست امنیت، مالکیت کد، اندازه و ماهیت Diff، شواهد پذیرش و نظر انسانی. هیچ‌کدام به‌تنهایی کامل نیستند. تست سبز می‌تواند نیاز اشتباه را اجرا کند؛ انسان ممکن است جزئیات را از دست بدهد؛ و AI ممکن است درباره رفتار Runtime یا زمینه سازمانی برداشت نادرست داشته باشد.

مستندات رسمی GitHub درباره Copilot Code Review نیز میان Approval Assessment و Approval مؤثر در Rule تفاوت می‌گذارد: ارزیابی در خلاصه Review نمایش داده می‌شود، اما به‌طور پیش‌فرض Required Approval را برآورده نمی‌کند. این جداسازی برای طراحی فرایند مفید است؛ ابتدا از AI به‌عنوان بازخورد استفاده کنید و فقط بعد از مشاهده کیفیت واقعی در Repository خود، درباره اثر آن بر Gate تصمیم بگیرید.

چه کسی پاسخ‌گو است؟

برای هر Repository یک انسان یا تیم مالک باید مشخص باشد. مالک نهایی فقط دکمه Approve نمی‌زند؛ او باید بداند کدام تست‌ها اجرا شده‌اند، کدام محدودیت‌ها خارج از پوشش‌اند و در صورت Incident چه کسی Rollback را هدایت می‌کند. اگر پاسخ‌گویی مشخص نباشد، اضافه‌کردن Approval بیشتر تنها ظاهر کنترل را قوی می‌کند.

گیت اول: Scope و معیار پذیرش پیش از دیدن Diff

بازبین باید پیش از خواندن خطوط تغییر، بداند Pull Request چه مسئله‌ای را حل می‌کند و چه چیزی عمداً خارج از Scope است. توضیح PR حداقل باید شامل مسئله، روش حل، ریسک، مسیر تست و برنامه بازگشت باشد. برای Bug، یک مثال قابل‌بازتولید و تست رگرسیون لازم است؛ برای Feature، سناریوی پذیرش؛ و برای Refactor، شواهدی که رفتار بیرونی ثابت مانده است.

• Issue یا نیاز کسب‌وکار به‌وضوح پیوند داده شده باشد.
• مرز «این PR انجام نمی‌دهد» نوشته شود تا پیشنهادهای جانبی مسیر را منحرف نکنند.
• تغییرات داده، API، Permission و Dependency جداگانه علامت‌گذاری شوند.
• روش تست دستی و خودکار قابل تکرار باشد.

AI در این مرحله می‌تواند ناسازگاری میان توضیح و Diff را پیدا کند، اما نمی‌تواند بدون زمینه سازمانی تصمیم بگیرد که معیار پذیرش درست تعریف شده است. تیم باید ابتدا قرارداد مسئله را روشن کند.

گیت دوم: Diff کوچک و قابل فهم

کیفیت Review با اندازه Pull Request رابطه مستقیم عملی دارد: هرچه تغییر نامرتبط بیشتر باشد، ساخت مدل ذهنی برای انسان و ماشین دشوارتر می‌شود. تغییر Format، Rename گسترده و منطق کسب‌وکار را در یک PR مخلوط نکنید. اگر Feature بزرگ است، آن را به برش‌هایی تقسیم کنید که هرکدام قابل Deploy یا دست‌کم قابل تست باشند.

برای نمونه، در یک API TypeScript می‌توان ابتدا قرارداد و Validation، سپس Persistence و بعد UI را جدا کرد. انتخاب زبان یا نوع‌گذاری نیز بر Review اثر دارد؛ راهنمای TypeScript یا JavaScript نشان می‌دهد نوع‌ها چگونه بخشی از قرارداد را آشکارتر می‌کنند، اما حتی TypeScript هم جای تست Runtime را نمی‌گیرد.

چک Diff پیش از Review

1. فایل‌های تولیدشده، Build Artifact و Secret به‌اشتباه Commit نشده باشند.
2. تغییر Lockfile با تغییر Dependency متناظر باشد.
3. Migration و کد مصرف‌کننده ترتیب Deploy سازگار داشته باشند.
4. تغییرهای صرفاً Formatting از منطق جدا شوند.
5. هر بخش بزرگ توضیح کوتاه یا Commit معنادار داشته باشد.

گیت سوم: CI مستقل و غیرقابل دورزدن

AI ممکن است اجرای تست را پیشنهاد کند یا نتیجه آن را تفسیر کند، اما Gate باید توسط سامانه CI و روی Commit مشخص enforce شود. Build، Unit Test، Integration Test، Lint، Type Check و اسکن Dependency باید متناسب با پروژه Required Status Check باشند. اگر تست فقط روی لپ‌تاپ نویسنده اجرا شده، بازبین مستقل شواهد کافی ندارد.

محیط تست باید تا جای ممکن تکرارپذیر باشد. Container می‌تواند نسخه Runtime و Dependencyهای سیستم را ثابت‌تر کند؛ مقاله Docker برای توسعه‌دهندگان مبانی این جداسازی را توضیح می‌دهد. با این حال Image قدیمی یا Test Data غیرواقعی می‌تواند نتیجه سبز کاذب بسازد، پس نسخه Image و داده آزمایش نیز باید مدیریت شوند.

• نام Checkها پایدار باشد تا Rule اشتباه به Job حذف‌شده اشاره نکند.
• Failure قابل بازتولید و Log آن برای بازبین خوانا باشد.
• Retry بی‌حد خطای Flaky را پنهان نکند.
• تست‌های امنیت و Migration در مسیرهای حساس اجباری باشند.

گیت چهارم: مالک کد برای نواحی حساس

همه فایل‌ها ریسک یکسان ندارند. Authentication، Authorization، Payment، Secret Management، CI/CD، Infrastructure، Database Migration و Logging داده حساس باید Code Owner مشخص داشته باشند. راهنمای Pull Request Review در GitHub Docs توضیح می‌دهد که CODEOWNERS می‌تواند هنگام تغییر فایل‌های تحت مالکیت، Review فرد یا تیم مربوط را خودکار درخواست کند.

مالکیت باید بر اساس دانش و مسئولیت واقعی باشد، نه صرفاً نام یک مدیر در فایل. برای پوشه پرداخت، کسی لازم است که Idempotency، واحد پول، Callback و سناریوی بازپرداخت را بفهمد. برای Migration، فردی که قفل، زمان اجرا، Rollback و سازگاری نسخه قبلی برنامه را می‌سنجد. AI می‌تواند Checklist را یادآوری کند، اما امضای تخصصی باید به فرد پاسخ‌گو متصل بماند.

گیت پنجم: تهدید و حریم خصوصی، جدا از کیفیت کد

خوانایی و تمیزی کد به معنی امنیت نیست. هر Pull Request حساس باید دست‌کم از چهار زاویه بررسی شود: ورودی غیرقابل اعتماد، کنترل دسترسی، افشای داده و مسیر سوءاستفاده. برای Endpoint جدید بپرسید چه کسی مجاز است آن را صدا بزند، Tenant چگونه جدا می‌شود، Rate Limit کجاست و Log چه داده‌ای را ثبت می‌کند.

در بازبینی AI، سیاست Context نیز مهم است. فایل‌های Secret، داده مشتری، Dump پایگاه‌داده و کلید خصوصی نباید برای گرفتن Review وارد Prompt شوند. اگر ابزار سازمانی Content Exclusion یا Policy دارد، آن را تنظیم کنید؛ اما همچنان فرض کنید کنترل فنی می‌تواند ناقص باشد و اصل «حداقل داده لازم» را در توضیح و Diff رعایت کنید.

پرسش‌های امنیتی کوتاه

• آیا مسیر جدید بدون Authentication قابل دسترسی است؟
• آیا نقش کاربر و مالکیت Resource هر دو بررسی می‌شوند؟
• آیا ورودی پیش از استفاده در SQL، HTML، Path یا Command محدود می‌شود؟
• آیا Error یا Log شامل Token، Password یا اطلاعات شخصی است؟
• آیا Dependency تازه منبع، مجوز و نسخه قابل قبول دارد؟

گیت ششم: شواهد برای هر Comment مهم

Comment بازبین—انسان یا AI—نباید صرفاً با لحن مطمئن پذیرفته شود. برای ادعای Bug یک تست شکست‌خورده، مسیر اجرای کد یا مستند معتبر بخواهید. برای ادعای Performance یک Benchmark یا Query Plan؛ برای ادعای Security یک Threat Scenario؛ و برای پیشنهاد Style یک Rule توافق‌شده تیم.

اگر AI پیشنهاد می‌کند Null Check اضافه شود، بررسی کنید آیا Type System یا Validation قبلی آن حالت را ناممکن کرده است. اگر حذف Query را پیشنهاد می‌دهد، اثر Transaction و Lazy Loading را بسنجید. مقاله اصول Prompt‌نویسی برای کدنویسی با AI روی زمینه و محدودیت تأکید دارد؛ در Review نیز ارائه نسخه Runtime، معماری و معیار پذیرش، پاسخ قابل‌ارزیابی‌تری می‌سازد.

1. Comment را به ادعای مشخص تبدیل کنید.
2. ادعا را با Test، Trace یا Documentation بررسی کنید.
3. اصلاح کوچک بسازید و تست رگرسیون اضافه کنید.
4. پس از Push، Review را روی SHA جدید تکرار کنید.

گیت هفتم: تأیید کهنه پس از Push معتبر نیست

یکی از خطاهای خطرناک گردش کار این است که PR تأیید شود و سپس Commit تازه‌ای بدون Review وارد شود. مستندات Branch Protection گزینه‌هایی مانند Dismiss stale approvals و الزام تأیید آخرین Push را توضیح می‌دهد. در اعلام قابلیت Approval هوش مصنوعی نیز GitHub می‌گوید با Push جدید، Approval Copilot کنار گذاشته می‌شود و Review تازه قابل درخواست است.

این قاعده باید برای هر بازبین یکسان باشد. نتیجه CI، خلاصه AI و تأیید انسان را به Commit SHA متصل کنید. Merge Queue یا Branch Protection باید جلوی Merge نسخه‌ای را بگیرد که با نسخه بررسی‌شده تفاوت دارد.

گیت هشتم: انسان آخرین تصمیم را با ریسک متناسب می‌گیرد

تأیید انسانی به معنی بازخوانی دستی تک‌تک خطوط در هر PR نیست؛ به معنی مالکیت تصمیم و انتخاب عمق متناسب با ریسک است. تغییر متن ساده می‌تواند با Checkهای سبک‌تر عبور کند، اما Migration یا Authorization به بازبین متخصص، تست سناریو و برنامه Rollback نیاز دارد.

اگر AI Approval در سازمان فعال می‌شود، ابتدا آن را در Repository کم‌ریسک و به‌صورت مشاهده‌ای ارزیابی کنید. نرخ Commentهای درست، موارد ردشده، Bugهای فراری و زمان Review را با تعریف روشن بسنجید. سپس Policy را بر اساس شواهد تغییر دهید، نه هیجان ابزار.

سناریوی اجرایی: PR تغییر سطح دسترسی

فرض کنید یک PR اجازه ویرایش پروفایل سازمان را اضافه می‌کند. نویسنده معیار پذیرش و Roleهای مجاز را می‌نویسد. Diff فقط Endpoint، Policy و تست‌های مرتبط را تغییر می‌دهد. CI تست Unauthorized، کاربر عضو و مدیر سازمان را اجرا می‌کند. CODEOWNER امنیت درخواست Review می‌گیرد. AI متوجه می‌شود TenantId از Route آمده، اما مالکیت Resource جداگانه بررسی نشده است.

تیم Comment را کورکورانه نمی‌پذیرد؛ یک تست می‌سازد که کاربر Tenant دیگر را شبیه‌سازی می‌کند. تست شکست می‌خورد، اصلاح انجام می‌شود و پس از Push جدید، Approvalهای قبلی باطل و Review تکرار می‌شوند. در نهایت انسان مسئول، شواهد و ریسک باقی‌مانده را می‌خواند و تصمیم Merge می‌گیرد. این همان جایی است که AI ارزش تولید می‌کند، بدون آن‌که مسئولیت را تصاحب کند.

چک‌لیست نهایی پیش از Merge

• Scope و معیار پذیرش روشن و قابل تست هستند.
• Diff تغییر نامرتبط یا Artifact ناخواسته ندارد.
• همه Required Checkها روی SHA فعلی سبز هستند.
• فایل‌های حساس تأیید Code Owner را دارند.
• ورودی، دسترسی، داده حساس و Dependency بررسی شده‌اند.
• Commentهای مهم با Test یا مستند معتبر تأیید شده‌اند.
• پس از آخرین Push، Review و Approval تازه گرفته شده است.
• مالک انسانی ریسک، Deploy و Rollback را پذیرفته است.

جمع‌بندی

بازبینی کد با هوش مصنوعی زمانی مفید است که به یک فرایند قابل ممیزی متصل شود. Scope روشن، Diff کوچک، CI اجباری، Code Owner، کنترل امنیت، شواهد برای Comment، بی‌اعتبارشدن تأیید کهنه و تصمیم نهایی انسانی، هشت گیتی هستند که سرعت را بدون حذف مسئولیت وارد تیم می‌کنند.

اگر می‌خواهید گردش کار Pull Request تیم‌تان را با گیت‌های قابل‌اندازه‌گیری، CI و بازبینی انسانی طراحی کنید، برای یک جلسه ارزیابی فرایند با خانه برنامه‌نویسان البرز در تماس باشید.