حل نظرات مرور کد با ML – Google AI Blog

ارسال شده توسط Alexander Frömmgen، مهندس نرم افزار کارکنان، و Lera Kharatyan، مهندس ارشد نرم افزار، سیستم های اصلی و تجربیات

بررسی های تغییر کد بخش مهمی از فرآیند توسعه نرم افزار در مقیاس است که مقدار قابل توجهی از زمان نویسندگان کد و بازبینان کد را می گیرد. به عنوان بخشی از این فرآیند، بازبینی کننده کد پیشنهادی را بررسی می کند و از نویسنده از طریق نظراتی که به زبان طبیعی نوشته شده است، تغییرات کد را درخواست می کند. در Google، ما سالانه میلیون‌ها نظر بازبین را می‌بینیم، و نویسندگان به طور متوسط ​​60 دقیقه از زمان ارسال تغییرات برای بازبینی و در نهایت ارسال تغییر، نیاز دارند. در اندازه‌گیری‌های ما، زمان کار فعال مورد نیاز که نویسنده کد باید برای رسیدگی به نظرات بازبین انجام دهد، تقریباً به صورت خطی با تعداد نظرات افزایش می‌یابد. با این حال، با یادگیری ماشین (ML)، ما فرصتی داریم تا فرآیند بررسی کد را خودکار و ساده کنیم، به عنوان مثال، با پیشنهاد تغییرات کد بر اساس متن نظر.

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

پیش بینی ویرایش کد

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

نمونه‌ای از ویرایش پیشنهادی ML از refactorings که در کد پخش می‌شوند.

Google از monorepo استفاده می‌کند، یک مخزن واحد برای همه مصنوعات نرم‌افزاری خود، که به مجموعه داده‌های آموزشی ما اجازه می‌دهد تمام کدهای نامحدود مورد استفاده برای ساخت جدیدترین نرم‌افزار Google و همچنین نسخه‌های قبلی را شامل شود.

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

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

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

مدل نهایی برای دقت هدف 50 درصد کالیبره شد. یعنی، ما مدل و فیلتر پیشنهادات را تنظیم کردیم، به طوری که 50٪ از ویرایش های پیشنهادی در مجموعه داده ارزیابی ما درست باشد. به طور کلی افزایش دقت هدف تعداد ویرایش های پیشنهادی نشان داده شده را کاهش می دهد و کاهش دقت هدف منجر به ویرایش های پیشنهادی نادرست بیشتر می شود. ویرایش‌های پیشنهادی نادرست توسعه‌دهندگان را زمان می‌برد و اعتماد توسعه‌دهندگان را به این ویژگی کاهش می‌دهد. ما دریافتیم که دقت هدف 50 درصد تعادل خوبی را فراهم می کند.

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

معماری زیرساخت ویرایش های پیشنهادی ML. ما کد و زیرساخت را از چندین سرویس پردازش می‌کنیم، پیش‌بینی‌های مدل را دریافت می‌کنیم و پیش‌بینی‌ها را در ابزار بررسی کد و IDE نشان می‌دهیم.

توسعه دهنده با ویرایش های پیشنهادی ML در ابزار بررسی کد و IDE تعامل دارد. بر اساس بینش‌های حاصل از مطالعات کاربر، ادغام در ابزار بررسی کد برای یک تجربه مرور ساده مناسب‌تر است. ادغام IDE عملکرد اضافی را ارائه می دهد و از ادغام 3 طرفه ویرایش های پیشنهادی ML (سمت چپ در شکل زیر) در صورت تغییرات محلی متناقض در بالای وضعیت کد بررسی شده (راست) در نتیجه ادغام (مرکز) پشتیبانی می کند.

UX ادغام سه طرفه در IDE.

نتایج

ارزیابی‌های آفلاین نشان می‌دهد که این مدل به 52% نظرات با دقت هدف 50% رسیدگی می‌کند. معیارهای آنلاین نسخه بتا و راه‌اندازی کامل داخلی این معیارهای آفلاین را تأیید می‌کنند، به‌عنوان مثال، ما پیشنهادات مدل را بالاتر از حد اطمینان مدل هدفمان برای حدود 50 درصد از تمام نظرات بازبین مرتبط می‌بینیم. 40٪ تا 50٪ از تمام ویرایش های پیشنهادی پیش نمایش شده توسط نویسندگان کد اعمال می شود.

ما از بازخورد “غیر مفید” در طول بتا برای شناسایی الگوهای شکست مکرر مدل استفاده کردیم. ما اکتشافی‌های زمان خدمت را برای فیلتر کردن این موارد و در نتیجه کاهش تعداد پیش‌بینی‌های نادرست نشان‌داده‌شده اجرا کردیم. با این تغییرات، کمیت را با کیفیت مبادله کردیم و شاهد افزایش نرخ پذیرش در دنیای واقعی بودیم.

ابزار بررسی کد UX. پیشنهاد به عنوان بخشی از نظر نشان داده می‌شود و می‌توان آن را پیش‌نمایش کرد، اعمال کرد و به‌عنوان مفید یا غیر مفید رتبه‌بندی کرد.

راه اندازی بتا ما یک نشان داد چالش کشف پذیری: نویسندگان کد فقط 20٪ از تمام ویرایش های پیشنهادی ایجاد شده را پیش نمایش کردند. ما UX را اصلاح کردیم و یک دکمه برجسته «نمایش ML-edit» (شکل بالا را ببینید) در کنار نظر بازبین معرفی کردیم، که منجر به نرخ پیش‌نمایش کلی ~40% در هنگام راه‌اندازی شد. علاوه بر این، دریافتیم که ویرایش‌های پیشنهادی در ابزار بررسی کد اغلب به دلیل تغییرات متناقضی که نویسنده در طول فرآیند بررسی انجام داده است، قابل اعمال نیستند. ما با یک دکمه در ابزار بررسی کد که IDE را در نمای ادغام برای ویرایش پیشنهادی باز می‌کند، به این موضوع پرداختیم. اکنون مشاهده می کنیم که بیش از 70٪ از این موارد در ابزار بررسی کد و کمتر از 30٪ در IDE اعمال می شود. همه این تغییرات به ما این امکان را می‌دهد که بخش کلی نظرات بازبین را که با ویرایش پیشنهادی ML با ضریب ۲ از نسخه بتا تا راه‌اندازی کامل داخلی بررسی می‌شوند، افزایش دهیم. در مقیاس گوگل، این نتایج به خودکارسازی حل صدها هزار نظر در هر سال کمک می کند.

قیف فیلتر پیشنهادات.

ما ویرایش‌های پیشنهادی ML را می‌بینیم که به طیف گسترده‌ای از نظرات بازبین در تولید رسیدگی می‌کنند. این شامل refactorings محلی و refactorings ساده است که در داخل کد پخش شده است، همانطور که در نمونه های سراسر پست وبلاگ بالا نشان داده شده است. این ویژگی به نظرات طولانی تر و با فرمول کمتری که نیاز به تولید کد، بازآفرینی و واردات دارند، می پردازد.

نمونه ای از پیشنهاد برای یک نظر طولانی تر و با فرمت کمتر که نیاز به تولید کد، بازسازی و واردات دارد.

این مدل همچنین می‌تواند به نظرات پیچیده پاسخ دهد و ویرایش‌های گسترده کد ایجاد کند (نشان داده شده در زیر). مورد آزمایشی تولید شده از الگوی تست واحد موجود پیروی می کند، در حالی که جزئیات را همانطور که در نظر توضیح داده شده تغییر می دهد. علاوه بر این، این ویرایش یک نام جامع برای آزمون پیشنهاد می‌کند که معانی آزمون را منعکس می‌کند.

نمونه ای از توانایی مدل برای پاسخ دادن به نظرات پیچیده و ایجاد ویرایش های گسترده کد.

نتیجه گیری و کار آینده

در این پست، ویژگی ML-assistance را برای کاهش زمان صرف شده برای تغییرات مربوط به بررسی کد معرفی کردیم. در حال حاضر، تعداد قابل توجهی از نظرات بررسی کد قابل اجرا در زبان‌های پشتیبانی شده با ویرایش‌های پیشنهادی ML در Google بررسی می‌شوند. یک آزمایش 12 هفته ای A/B در همه توسعه دهندگان Google، تأثیر این ویژگی را بر بهره وری کلی توسعه دهندگان بیشتر اندازه گیری می کند.

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

سپاسگزاریها

این کار بسیاری از افراد در تیم Google Core Systems & Experiences، Google Research و DeepMind است. مایلیم به طور خاص از پیتر چوی برای گردآوری این همکاری، و از همه اعضای تیم خود برای کمک های کلیدی و توصیه های مفیدشان، از جمله مارکوس رواج، گابریلا سوریتا، ماکسیم تاباچنیک، جیکوب آستین، نیمش گلانی، دن ژنگ، پیتر جوسلینگ تشکر کنیم. ماریانا استاریولو، کریس گورگولوسکی، ساشا وارکویسر، کاتیا گرونودل، آلبرتو الیزوندو، توبیاس ولپ، پیج بیلی، پیر آنتوان مانزاگول، پاسکال لامبلین، چنجی گو، پتروس مانیاتیس، هنریک میچالوسکی، سارا ویلتبرگاون، سارا ویلتبرگاون، سارا ویلتبرگاون، سارا ویلتبرگاون، سارا ویلت‌برگاون، سارا مادلوگر، نیرانجان تولپول، زوبین قهرمانی، خوانجو کارین، دنی تارلو، کوین ویللا، استویان نیکولوف، دیوید تاترسال، بوریس بوکوفسکی، کتی نیکس، مهدی گیساسی، لوئیس سی کوبو، یوجیا لی، دیوید چوی، کریستوف مولناندر، وایتل، وایتل ، برت ویلتشایر، لورن لو برون، مینگپن گوئو، هرمان لوس، جوناس ماتس، ساوین دنس.