بازبینی کد با هوش مصنوعی: چه میبیند و چه نمیبیند
کد ریویو خودکار در پیدا کردن غفلتهای کوچک عالی است و در فهمیدن اینکه این کد اصلاً باید نوشته میشد یا نه، کور. تفکیک این دو، همهی ماجراست.
یک پول ریکوئست چهارصدخطی در صف مانده و کسی حوصلهی بازکردنش را ندارد. سه روز بعد با یک «بهنظر خوبه» تأیید میشود. این اتفاق در بیشتر تیمهای کوچک میافتد و همانجاست که باگهای گران وارد کد میشوند.
ابزار هوشمند این مشکل را کامل حل نمیکند، ولی یک لایهی اول ارزان اضافه میکند: چیزهایی که هیچ آدمی نباید وقتش را صرفشان کند، قبل از رسیدن به چشم انسان گرفته میشوند. شرطش این است که بدانید چه انتظاری از آن داشته باشید.
چه چیزهایی را خوب میبیند
دستهی اول، غفلتهای مکانیکی است. مقداری که بررسی نشده و ممکن است null باشد، خطایی که گرفته شده ولی نادیده رد شده، حلقهای که داخلش کوئری میزند، متغیری که ساخته شده و استفاده نشده. اینها ایرادهایی هستند که آدم خسته در ساعت شش عصر رد میشود.
دستهی دوم، ناسازگاری داخلی است: تابعی که در توضیحش نوشته آرایه برمیگرداند و در یک شاخه null میدهد. یا نامی که با بقیهی کد جور نیست.
دستهی سوم، الگوهای امنیتی شناختهشده. رشتهی کوئری که با چسباندن ورودی ساخته شده، خروجی بدون فرار دادن، کلید داخل سورس. برای این دسته، چسباندن فهرست ده ریسک برتر OWASP به پرامپت، دقت را محسوس بالا میبرد.
چه چیزهایی را نمیبیند
مهمترین کور بودنش این است: نمیداند این کد اصلاً باید نوشته میشد یا نه. اگر کسی از اول تابعی نوشته که سه ماه پیش در جای دیگری نوشته شده، مدل کیفیت همان تابع را بررسی میکند و تکراری بودنش را نمیفهمد.
- تصمیم معماری. اینکه این منطق باید در این لایه باشد یا نه، به قرارداد تیم برمیگردد، نه به کد.
- نقص دسترسی. کدی که کاربر الف را به دادهی کاربر ب میرساند، از نظر نحوی بیعیب است.
- هزینهی واقعی اجرا. کوئریای که روی هزار رکورد سریع است و روی ده میلیون رکورد سرور را میخواباند.
- الزام کسبوکار. اینکه محاسبهی مالیات یا تخفیف طبق قاعدهی واقعی شرکت شماست یا نه.
اگر خروجی بازبینی چیزی نگفت، معنیاش این نیست که کد سالم است. یعنی در آنچه دیده، الگوی مشکوکی نبوده. برای کد حساس — پرداخت، احراز هویت، دسترسی — بازبینی انسانی همچنان لازم است، بیهیچ استثنایی.
پرامپتی که خروجی قابل استفاده میدهد
بازبینی بدون دستور، فهرستی از نکتههای سلیقهای تحویل میدهد که هیچکس نمیخواندشان. اولویتبندی را خودتان تحمیل کنید:
این تغییر را مرور کن. زمینه: [نقش این ماژول در سیستم].
خروجی را در سه سطح بده:
🔴 باگ یا ریسک امنیتی — با سناریویی که خراب میشود
🟡 مشکل احتمالی — با دلیل و شرط وقوع
🔵 پیشنهاد اختیاری
قواعد:
- سلیقهی نامگذاری و قالببندی را کاری نداشته باش
- برای هر مورد شمارهی خط بده
- اگر برای قضاوت زمینهی کافی نداری، بپرس؛ حدس نزن
- اگر چیزی پیدا نکردی، بنویس «موردی نیست»
--- تغییرات:
[diff]بند «حدس نزن» بیشترین اثر را دارد. بدون آن، مدل دربارهی تابعی که نمیبیند فرض میسازد و شما را دنبال ایراد ناموجود میفرستد.
کدام ایراد، چه دقتی
| نوع ایراد | دقت | نکته |
|---|---|---|
| مقدار بررسینشده و خطای رد شده | بالا | بیشترین برد روزمره |
| کوئری داخل حلقه | بالا | معمولاً همراه با راهحل درست |
| تزریق و ورودی فرار دادهنشده | بالا | الگو شناختهشده است |
| حالت لبه در منطق | متوسط | بعضی را میبیند، همه را نه |
| همزمانی و شرایط رقابتی | متوسط | نیازمند دیدن کل جریان |
| کارایی در مقیاس واقعی | پایین | اندازهی داده را نمیداند |
| درستی قاعدهی کسبوکار | پایین | قاعده را ندیده است |
| تناسب با معماری تیم | پایین | قرارداد تیم را نمیداند |
جای درستش در فرایند تیم
قبل از باز کردن پول ریکوئست، نه بعدش. نویسندهی کد خودش یک بار مرور میگیرد، موارد قرمز را اصلاح میکند و بعد برای انسان میفرستد. نتیجهاش این است که مرورگر انسانی وقتش را صرف چیزی میکند که فقط او میتواند ببیند — تصمیم و طراحی.
یک عادت که در تیمهای کوچک خوب جواب داده: خروجی مرور را در کامنت پول ریکوئست نچسبانید. فقط آنچه را واقعاً اصلاح کردهاید بنویسید. چسباندن فهرست خام، نویز میسازد و بعد از دو هفته کسی نمیخواندش.
برای تغییرات بزرگ، ترتیب کار همان چیزی است که در مهاجرت کد و ارتقای نسخه آمده: تکههای کوچک، هر کدام جدا مرور و کامیت شوند.
مرور بهعلاوهی تست
مؤثرترین ترکیب این است که بهجای «این کد را مرور کن»، بخواهید تستی بنویسد که کد را بشکند. مدل مجبور میشود سناریوی مشخص بسازد و همانجا معلوم میشود ایرادش واقعی است یا نه. تستی که پاس شود، ایراد را رد میکند؛ تستی که رد شود، باگ را ثابت میکند. روش کاملترش در هوش مصنوعی برای تست نرمافزار آمده.
جمعبندی
بازبینی خودکار جایگزین مرور انسانی نیست؛ کف کیفیت را بالا میبرد. ایرادهای مکانیکی را میگیرد تا آدمها به سؤالهای مهمتر برسند: این تغییر لازم بود؟ در جای درستی نشسته؟ شش ماه دیگر کسی میفهمدش؟
قاعدهی نهایی همان قاعدهی همیشگی است: هر ایرادی که دلیلش را نفهمیدید، نپذیرید و اصلاحش نکنید. راهنمای مرور کد گوگل برای ساختن معیار تیمی منبع خوبی است، و مبانی کار با کد در هوش مصنوعی برای برنامهنویسی جمع شده. برای امتحان روی یک تغییر واقعی، نارنگی کافی است.
مطالب مرتبط:
