Міграція коду допомагає покращити продуктивність і стійкість, підтримує системи в актуальному стані та видаляє застарілий або нерелевантний код. Але це може бути складним і трудомістким, адже код дуже часто розкиданий у різних середовищах. І хоча ШІ з’явився для підтримки низки програмних завдань нижчого рівня, ця технологія ще не в змозі впоратися із заплутаною роботою міграції коду.
Тепер у Google кажуть, що, можливо, подолали цю проблему, запропонувавши новий покроковий процес і загальний інструментарій, за допомогою якого великі мовні моделі (LLM) знаходять файли, які потрібно змінити. Про це повідомляє InfoWorld.
Технологічний гігант вже каже, що прискорив міграцію на 50%.
«Цей підхід може радикально змінити спосіб підтримки коду на великих підприємствах. Це може не тільки прискорити роботу інженерів, але й зробити можливими зусилля, які раніше були нездійсненними через величезні інвестиції», — написала група авторів із Google Core та Google Ads у новому звіті про досвід, описуючи свій підхід.
Зрештою, мета Google полягала в тому, щоб визначити можливості для LLM для надання додаткової цінності та масштабу підтримки без потреби у складних для підтримки абстрактних синтаксичних деревах (AST).
Вони широко використовуються для представлення структури програми або фрагмента коду, але є детермінованими. Тобто результати вже визначені, а випадки використання міграції коду охоплюють набагато складніші конструкції, які важко представити за допомогою AST, пояснили автори.
«Досягти успіху в міграції коду на основі LLM непросто. Використання лише LLM через просту підказку недостатньо для найпростіших міграцій. Натомість, як ми з’ясували під час наших подорожей і як описано у тематичних дослідженнях у цій статті, для досягнення успіху необхідна комбінація методів на основі AST, евристик і LLM. Окрім того, важливо впроваджувати зміни безпечним способом, щоб уникнути дорогих регресій», — зазначили фахівці.
Google визначив успіх як штучний інтелект, який заощаджує щонайменше 50% часу для наскрізної роботи. Це охоплює переписування коду, визначення місць міграції, перегляди й остаточне розгортання. Як повідомили інженери, ця віха була досягнута. Зрештою 80% модифікацій коду були повністю створені ШІ.
«Анекдотичні зауваження розробників свідчать про те, що навіть якщо зміни не ідеальні, є значна цінність у тому, щоб початкова версія списку змін уже була створена», — йдеться у звіті.
Один із найбільших бізнес-підрозділів Google Google Ads побудований на базі коду із понад 500 мільйонів рядків. Він має десятки числових типів унікальних ідентифікаторів, які посилаються на різні ресурси (дескриптори), такі як користувачі, продавці та кампанії. Зазвичай вони визначаються як 32-розрядні цілі числа в C++ і Java, однак їх потрібно було перетворити на 64-бітні ідентифікатори, щоб уникнути сценаріїв, коли значення ідентифікатора було б занадто великим, щоб його можна було розмістити за допомогою 32-біт.
Перехід від 32-розрядної до 64-розрядної версії пов’язаний із численними труднощами. У Google ідентифікатори мають дуже загальне визначення, і їх нелегко знайти. Це робить процес за допомогою статичних інструментів нетривіальним й ускладнюється тим, що Google Ads містить десятки тисяч кодів, що робить відстеження змін надзвичайно складним.
Це одна зі сфер, де Google застосував свій процес міграції коду на базі LLM. На першому кроці інженер знаходить ідентифікатори, надмножини файлів і місця, які потрібно перенести. Потім зміни генеруються в LLM, створюючи цикл тестування й ітерації. Нарешті інженер переглядає згенерований LLM код (як і будь-який інший код), змінюючи та виправляючи за потреби. Потім зміни розділяються (розбиваються на фрагменти) і надсилаються для остаточного перегляду власникам кожної частини кодової бази.
В іншому прикладі група команд у Google мала значний набір тестових файлів, які все ще використовували застарілу бібліотеку JUnit3, фреймворк модульного тестування з відкритим кодом для Java. Оновлення вручну було б значним капіталовкладенням, а старі тести можуть негативно вплинути на кодову базу, пояснили автори Google.
«Вони є технічним боргом і здебільшого копіюються, оскільки розробники можуть ненавмисно скопіювати старий код для створення нового коду», — написали вони.
Розробники Google використовували LLM, щоб оновити те, що вони назвали критичною масою тестів JUnit3, до нової бібліотеки JUnit4. За допомогою цієї техніки вони змогли перенести 5359 файлів, змінивши понад 149 000 рядків коду за 3 місяці.
Автори звіту зазначили: «Ми вважаємо, що описані методи не є специфічними для Google, і очікуємо, що їх можна буде застосувати до будь-якої міграції коду на базі LLM на великих підприємствах. Набір інструментів є універсальним і може використовуватися для міграції коду з різними вимогами та результатами».
Читайте також на ProIT: Google анонсує експериментальну модель штучного інтелекту Gemini, яка вміє думати.
Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!
