بررسی کد بیشتر از تشخیص (قابلیت خودکار) است

چکیده مقاله “The End of Code Review: Coding Agents Jay Human Inspection” این تصویر را برای خواننده ترسیم می کند…

چکیده - بررسی کد از زمانی که فاگان بازرسی کد را در سال 1976 رسمی کرد، دروازه کیفیت اولیه در توسعه نرم افزار بوده است. برای پنج دهه، بررسی و اظهار نظر انسانی در مورد تغییرات همکار قبل از ادغام، سنگ بنای کار سازمان ها در هر اندازه بوده است. عوامل کدگذاری سیستم‌های مستقل مبتنی بر مدل زبان بزرگ (LLM) هستند که قادر به خواندن، نوشتن، تست و تعمیر نرم‌افزار هستند. ما استدلال می‌کنیم که عوامل کدگذاری از آستانه‌ای از قابلیت عبور کرده‌اند که در آن بازبینی کدهای انسانی سنتی دیگر جزء ضروری خط لوله کیفیت نرم‌افزار نیست.

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

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

نویسنده بررسی کد همتا را به چهار عملکرد بیان شده تجزیه می کند: تشخیص نقص، اجرای سبک، انتقال دانش و آگاهی. این استدلال می کند که یک عامل می تواند هر یک را انجام دهد. البته نتیجه این است که اگر یک عامل بتواند هر یک از آن توابع را اجرا کند، در آن صورت عامل توانایی جایگزینی یک بازبین انسانی را دارد.

من فکر می کنم که این برخی از جنبه های مهم بررسی کد همتا را نادیده می گیرد که نمی توان آنها را به یک تابع کاهش داد:

وقتی یک مهندس باتجربه تفاوتی را می‌خواند و می‌گوید «من این را نمی‌فهمم.»، سردرگمی آن‌ها متوجه می‌شوند. به این معنی است که کد یا خیلی پیچیده است، انتزاع اشتباه است، یا هدف آن مشخص نیست. یک LLM همیشه کد را به این معنا که بتواند آن را پردازش کند، "درک" می کند. نمی تواند سیگنال عدم درک مشروع انسانی را به شما بدهد. این مقاله قابل درک بودن را به عنوان چیزی که بیش از هر چیز دیگری به سبک مربوط می شود، در نظر می گیرد. این نیست. این یک ویژگی اضطراری است و در تعامل بین فردی که تلاش می کند مصنوع و خود مصنوع را درک کند، ظاهر می شود.

تردید واجد شرایط در مورد اینکه آیا تغییر حتی ضروری است یا خیر

اینها سوالاتی در مورد قصد، دامنه و مناسب بودن تغییر هستند. همه اینها قبل از اینکه آیا کد "صحیح" باشد، مطرح می شود. چارچوب مقاله فرض می کند که الف) تغییر کد در حال بررسی ضروری است، و ب) هدف اصلی بررسی، تأیید است. اما هر کسی که تا به حال با تولید تماس داشته است، می‌داند که بازبینی کد اغلب آخرین (یا گاهی اوقات تنها) لحظه‌ای است که می‌توان از کسی انتظار داشت که آیا تغییر حتی ضروری است یا خیر.

یک بازبین انسانی می تواند متوجه شود که یک قرارداد API تغییر کرده است اما رسیدگی به خطا تغییر نکرده است. آنها می توانند آنچه را که گم شده است متوجه شوند. به عبارت دیگر: توانایی تشخیص آنچه که انتظار می رود وجود داشته باشد، اما نیست. مقاله به هیچ وجه این موضوع را تأیید نمی کند، که به ویژه جالب است، زیرا غیبت کوری دقیقا همان کلاس شکستی است که LLM ها در آن بسیار ضعیف هستند. نماینده آنچه را که وجود دارد بررسی می کند. مهندسان با تخصص می توانند به راحتی متوجه موارد گم شده شوند.

چه کسی کد را نوشته است بر بررسی دقیق بررسی تأثیر می گذارد

بازبینان کد همتا نوعی توجه مدرج دارند که ناشی از تجربه قبلی نویسنده کد است که اغلب یک همکار است. به عنوان مثال: اولین تعهد یک مهندس کم سابقه به مثلا یک ماژول پرداخت، احتمالا توجه متفاوتی را نسبت به بازسازی معمول مهندس کهنه کار و «ریش خاکستری» جلب خواهد کرد. بازبین‌ها معمولا موقعیت‌های چه کسی، چه چیزی، چه زمانی و کجا را با تجربه خودشان در مورد اینکه خطر در کجا قرار دارد مطابقت می‌دهند. به نظر می رسد این مقاله همه تفاوت ها را به عنوان ورودی های معادل در نظر می گیرد.

بررسی کد دو طرفه و سازنده است

به نظر من کاغذ انتقال دانش را فقط به تحویل اطلاعات کاهش می دهد. عامل به سادگی «توضیحات را ایجاد می کند.» اما بحث در بررسی کد یک فعالیت شناختی مشترک است. داور همتا درباره رویکرد نویسنده می‌آموزد، نویسنده از طریق سؤالات بازبینان می‌آموزد، و نتیجه یک درک مشترک است که هیچ یک از طرفین قبل از بحث نداشتند.

این کار مشارکتی است، نه صرفا یک انتقال. خلاصه یک نماینده جایگزین مکالمه ای نیست که مدل ذهنی هر دو شرکت کننده را تغییر دهد.

سه شنبه گذشته در این سرویس یک حادثه داشتیم.

تیمی که این مصرف کننده پایین دستی را در اختیار دارد در شرف منسوخ کردن آن رابط است.

"قانونی به ما گفت که دیگر وارد این فیلد نشویم."

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

مسئولیت پذیری برای کد فقط یک تشریفات اداری نیست

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

در حالی که این مقاله نگرانی‌های اخلاقی را در بخش بحث خود گنجانده است، اما در نهایت آن را به سمت «مهندسی نیازمندی‌ها و نظارت پس از استقرار» هدایت می‌کند که به نظر من روشی است که با دست تکان می‌دهم برای لگد زدن به قوطی در جاده.

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

اما بازنگری کد همچنین یک فرآیند هماهنگی، یک فرآیند معنادار و یک فرآیند حاکمیتی است.

افسانه جانشینی اغلب به همین شکل انجام می شود:

این رویکرد اغلب در یک نقطه از هم می پاشد: مشارکت انسانی که بیش از همه مهم بود، ادغام بین عملکردها بود. توانایی افراد برای انطباق با شرایط و زمینه های برنامه ریزی نشده و خدمت به مسئولیت اجتماعی مورد انتظار.

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