ШІ-рефакторинг коду: автоматизація, безпека, швидкість

Застаріла кодова база: де AI-рефакторинг коду буксує

Найдорожча поломка в застарілому коді виглядає буденно: правка однієї умови в модулі розрахунків тягне за собою перезбирання звітності, обміну із зовнішніми системами й нічного перерахунку залишків.

Сама зміна займає години, а перевірка — весь релізний цикл, бо повного списку зачеплених місць ніхто не тримає в голові.

Корінь — зв'язаність модулів і приховані залежності. Логіка оподаткування продубльована в трьох місцях, стан змінюється з обробників подій в обхід шару доступу до даних, частина викликів іде напряму через рівні.

Статичний аналіз рівня SonarQube покаже дублі й довгі методи, але не покаже, що видалення «мертвої» гілки ламає розрахунки з клієнтами — це знання живе у двох інженерів і зникає разом із ними.

Технічний борг тут вимірюється не рядками, а ціною зміни: зростає частка правок, що зачіпають більше п'яти файлів, і падає частка правок із передбачуваним результатом.

Саме на цьому AI-рефакторинг коду буксує — модель упевнено переписує окремий файл, але не бачить систему: без карти залежностей будь-яке «покращення» або нічого не змінює, або відтворює ту саму зв'язаність у новому синтаксисі.

Розбираємо, як це закривається: спершу будується карта зв'язків і дублів по репозиторію, потім зміна нарізається на кроки, кожен із яких перевіряється тестами й може бути відкочений.

Швидкість збирання, клас зниклих відмов, час на доопрацювання

Ефект рефакторингу вимірюється не «стало чистіше», а чотирма числами: час збирання, час прогону перевірок, кількість правок-луною на сотню змін і частка релізів із відкатом.

Ми знімаємо ці значення до старту й повторюємо після — інакше розмова про якість коду залишається смаковою і не захищається на нараді.

Перший клас відмов, який зникає, — звернення до порожніх значень, гонки під час паралельного запису до спільного кешу, необроблені винятки в асинхронних викликах.

Правила аналізу вибудовуємо під проєкт вручну: базові набори в SonarQube дають багато шуму, і команда звикає гортати звіт не читаючи. Налаштований набір відсікає ці дефекти до злиття гілки, а не на розборі інциденту.

Час збирання й час перевірок падають завдяки видаленню дублів логіки та мертвих гілок: збирання скорочується з 18 до 7 хвилин, прогін тестів — з 40 до 15, бо набір перестає ганяти невикористовувані шляхи.

Покриття перевірками на змінений код піднімаємо з третини до двох третин — регрес ловиться до релізу, а не в день випуску.

Час на доопрацювання з'їдають правки-луною: та сама помилка живе в п'яти копіях функції й виправляється п'ять разів у різних місцях. Після виділення спільних модулів виправлення робиться один раз, а не в чотирьох.

Стабільність релізів зростає як наслідок: частка відкатів падає втричі, гарячі правки на проді перестають бути регулярною практикою, і планування наступної ітерації не розсипається.

Режими автоматизації: пакетний розбір, порційний, гібридний

Вибір режиму визначається двома властивостями бази: обсягом і зв'язаністю. Якщо модулі обмінюються даними через спільні структури й десятки точок виклику, правки не можна вносити ізольовано — спершу фіксуємо межі змін і порядок їх застосування. Нижче порівняння за критерієм «коли підходить / обмеження», яким ми користуємося на етапі оцінки.

На практиці найчастіше стартуємо з пакетного розбору на периферійних модулях: він швидко показує, де зв'язаність вища за очікувану, і уточнює карту залежностей. Далі щільно зв'язане ядро переходить у порційну обробку, а решту підхоплюють інкрементальні правки.

Такий гібридний режим дає передбачуваний розмір порції на рев'ю — перевіряльник бачить один логічно цілісний блок, а не сотню розрізнених рядків.

Як будується робота: від розбору репозиторію до передачі

Рефакторинг із залученням моделі починається не з правок, а з інвентаризації: поки немає карти залежностей і меж модулів, будь-яка автоматична зміна зачіпає суміжний код. Тому робота йде етапами, і кожен завершується артефактом, який можна перевірити до переходу до наступного.

1. Аудит репозиторію. Дивимося структуру, історію змін, дубльовані ділянки й те, чим покриті тести. На виході — перелік зон ризику: де правки дадуть ефект, а де чіпати код дорожче, ніж залишити.
2. Карта залежностей. Будуємо граф зв'язків між модулями й зовнішніми бібліотеками, позначаємо цикли та неявні зв'язки через спільний стан. Карта задає порядок: спершу ізольовані модулі, потім периферія, ядро останнім.
3. Правила перевірок. Фіксуємо, що вважається коректною зміною — стиль, обробка помилок, заборона на певні конструкції. Правила ставляться в лінтери й у збирання, щоб відхиляти правку автоматично, а не на рев'ю.
4. Порційні правки. Зміни вносяться невеликими наборами, у кожної порції одна мета. Рев'ю залишається оглядовим, а невдалу порцію можна відкотити, не розбираючи весь обсяг.
5. Приймальні перевірки. Проганяємо тести й порівнюємо поведінку до й після на контрольних сценаріях. Якщо покриття не вистачає, спочатку дописуємо тести на зачеплені шляхи.
6. Передача. Віддаємо схему, правила перевірок, журнал порцій і список того, що свідомо залишили поза рефакторингом.

Далі ваша команда працює за тими самими правилами самостійно — без залежності від нас.

Що залишається в репозиторії та в документації після передачі

Автоматизований рефакторинг дає результат лише тоді, коли команда продовжує змінювати код без авторів правок. Тому передача — це не набір змінених файлів, а робоче середовище: правила, за якими код приводиться до єдиного вигляду, межі модулів і порядок дій у разі збою. Що саме залишається у вас на руках:

• Конфігурація правил — файли налаштувань статичного аналізу й автовиправлень із поясненням, чому правило увімкнено або вимкнено та які винятки зроблено для успадкованого коду.
• Схема модулів — карта зв'язків між компонентами: де проведено межі, які залежності дозволені, які вважаються порушенням і падають на перевірці.
• Регламент рев'ю — що перевіряє автор зміни, що автоматика, які розбіжності блокують злиття і хто ухвалює рішення у спірних випадках.
• Інструкція з відкату — покрокове повернення гілки до попереднього стану з перевіркою сумісності змін схеми даних і без втрати накопичених правок.
• Документація щодо інтерфейсів — поведінка публічних функцій у разі помилок і перелік місць, де автоматика навмисно не застосовувалася, щоб їх не переписали наосліп.
• Звіт про покриття — які шляхи закриті перевірками, які залишилися без них і чому.

Усе це лежить у репозиторії поруч із кодом і оновлюється тими самими перевірками — інакше інструкції застарівають швидше, ніж їх устигають прочитати.

Кейс: рефакторинг платіжного модуля без зупинки продукту

Платіжний модуль — місце, де правка коштує найдорожче: через нього йдуть списання, повернення й звірка з провайдерами, помилка видна клієнту одразу.

Перед стартом зняли базові заміри: час відповіді на типові операції, частку відмов за журналами, складність ключових функцій і те, яка частина коду закрита перевірками. Ці цифри стали точкою відліку — за ними й порівнювали результат.

До: де саме боліло

Основні сценарії жили в одній довгій функції з розгалуженнями на кожен спосіб оплати й тип повернення. Правка в одному місці зачіпала сусідні, будь-яка зміна тягнула ручний прогін усього модуля, а заміри показували: приблизно третина логіки не закрита автоматичними перевірками.

Після: заміри та відсутність регресій

Правили порціями: спочатку платіж, потім повернення, потім повідомлення провайдера. Кожну порцію вмикали перемикачем на живому трафіку — нова й стара гілки рахували одні й ті самі операції паралельно, результати звірялися порядково.

Після здачі складність ключових функцій упала приблизно вдвічі, час відповіді скоротився майже втричі, покриття перевірками зросло з третини до майже повного.

Регресій не сталося: їх відловлювали набором перевірок на історичних операціях, паралельним прогоном двох гілок і поступовим перемиканням частками трафіку. Контрольні суми за журналом платежів звіряли порядково — розбіжність в одному записі повертала попередню версію.

Заміри знімали тими самими інструментами, що й до старту: SonarQube — складність і покриття, внутрішні графіки моніторингу — затримки й частку відмов.

Що робити, якщо в проєкті немає тестів і зрозумілої документації?

Правки в проєкті без тестів упираються в одне: незрозуміло, що вважати працюючим. Формально задачу розв'язано, а чи зламалося щось на сусідньому шляху, ніхто сказати не може. Тому перший крок — не переписування коду, а фіксація тієї поведінки, яку система видає зараз.

Фіксація йде від спостережуваного, а не від бажаного.

Ми проганяємо реальні сценарії на копії даних, знімаємо входи й виходи публічних модулів і пишемо характеризаційні перевірки, які описують поточну поведінку як є — включно з дивними гілками, округленнями й обробкою порожніх значень.

Такі перевірки не претендують на правильність результату, їхнє завдання — помітити, що він змінився.

Паралельно збирається опис системи: карта модулів, напрямки викликів, місця, де дані змінюються, зовнішні залежності й побічні ефекти. Модель прискорює цю роботу — читає код і чернетку карти, а інженер перевіряє кожну гілку на живому виклику. Документ виходить коротким і по суті: не переказ коду, а межі модулів і домовленості між ними.

Далі — порядок правок. Змінюємо по одній ділянці за раз, від периферії до ядра, і після кожного кроку проганяємо накопичений набір перевірок. Точки контролю ставляться там, де зміну видно ззовні: відповідь на запит, запис у сховище, надіслана подія. Якщо перевірка червоніє, відкат до попереднього стану займає хвилини, а не години розбору.

До кінця етапу проєкт перестає бути чорною скринькою: є набір перевірок на поточну поведінку, стислий опис системи й точки контролю. Це та страховка, після якої AI-рефакторинг і автоматизація правок перестають бути ризиком — будь-яку зміну видно й відкочується.

Технічні сумніви: безпека, приватність, відкат змін

Інженери слушно запитують, що відбувається з репозиторієм, коли до нього підключають автоматичний рефакторинг. Агент не чіпає бойову гілку: він працює в ізольованому контурі на копії коду, доступ видається короткоживучими токенами з областю видимості на один репозиторій. Звернення й команди логуються так само, як для штатного інженера.

Правки надходять окремими наборами змін, а не записом в основну гілку. Кожен набір проходить автотести й статичний аналіз, зміни розбиті на невеликі кроки зі зрозумілим описом — відкочується й окрема правка, і вся серія, без перезбирання релізу. Нижче — три сумніви, які найчастіше лунають на старті.

Чи можна відкотити серію правок?

Так. Рефакторинг розкладається на атомарні кроки, тому скасовується й окрема правка, і вся серія. Тести й збирання на кожному кроці показують точку, де поведінка системи розійшлася з очікуваною.

Хто відповідає за регресії?

Межі фіксуємо до старту: які модулі чіпаємо, які контракти вважаємо незмінними, якими перевірками підтверджуємо поведінку. Непокриту ділянку закриваємо тестом до правки — зміна не проходить далі, якщо поведінка зламалася.

Обговоримо задачу: що надіслати, щоб отримати оцінку та план

Щоб повернутися з оцінкою робіт і планом робіт, повний доступ до коду не потрібен — на першому кроці достатньо вхідних даних, які зазвичай є під рукою. За ними видно обсяг, клас задач і те, де автоматизація дасть віддачу, а де доведеться йти вручну. Важливо заздалегідь проговорити обмеження доступу: від них залежать і схема роботи, і строки.

• Структура коду: дерево каталогів, найбільші модулі, де зосереджена основна логіка й куди сходяться залежності.
• Обсяг і стан: кількість файлів, ділянки, які давно не чіпали, частка коду, не покритого перевірками.
• Часті місця правок: файли, які змінюються найчастіше — там рефакторинг окупається найшвидше.
• Правила проєкту: прийнятий стиль, лінтери, регламент перевірки змін, що не можна змінювати за жодних умов.
• Обмеження доступу: чи можна працювати на копії сховища, чи є ізольований контур, які дані заборонено виносити за його межі.
• Дві-три типові задачі: приклади правок, які хотілося б прискорити, — за ними ми звіряємо очікування.
• Мета: прискорити випуск змін, знизити кількість дефектів або підготувати міграцію на іншу гілку розвитку.

Далі обговорення задачі займає одну розмову: ми ставимо уточнювальні запитання, звіряємо обмеження й повертаємося з оцінкою строків, розбивкою за етапами та зрозумілим критерієм готовності. Опишіть задачу й надішліть вхідні дані — цього достатньо, щоб почати.