- Виклик
- У кодовій базі, що росла роками, немає чистих швів. Змінюєш один файл — ламаються десять інших, бо ніде не зафіксовано, що від чого насправді залежить. Саме тому команди обирають переписування з нуля: воно виглядає єдиним виходом. Ми ж хотіли відповісти на інше питання — чи можна рухати велику заплутану систему частинами, доводячи поведінку кожної частини до і після переносу.
- Рішення
- Спершу ми побудували карту залежностей усього застосунку на 44 000 рядків і за нею розрізали його на 14 упорядкованих юнітів — так, щоб кожен переносився вже разом із тим, від чого залежить. Далі юніт за юнітом переносили AI-агенти, працюючи за цим порядком, а навколо кожного юніта ще до переносу писалися характеризаційні тести, які фіксували поведінку замість припущень про неї. Публічний API весь час лишався стабільним, тож наявні клієнти продовжували працювати під час міграції. Перебудований шар даних замінив рукописні запити на асинхронний ORM, а найбільші функції були розбиті на невеликі частини, які тестуються окремо.
- Результат
- Перенесено 11 із 14 юнітів — 79% системи — з 918+ написаними тестами, 576+ прибраними надлишковими запитами до бази і жодним зламаним API-ендпоінтом за весь час. Система лишалася робочою весь період. Ми зупинилися на 79%, бо метод на той момент був доведений: це був R&D, а не продукт, який ми випускали.
R&D
Міграція legacy-системи на 44 000 рядків — юніт за юнітом.
Більшість переписувань legacy провалюються однаково: команда зникає на рік, стара система тим часом змінюється, а нова приходить з іншою поведінкою, яку ніхто не може довести. Ми хотіли метод, за якого система лишається робочою від першого дня до останнього, — і спершу перевірили його на собі, а не на клієнті.
Це R&D, який ми проводили самі, — наша спроможність, а не клієнтська продакшен-система. Усі цифри на цій сторінці взяті саме з цього R&D-запуску.
Модернізація legacy · R&D-проєкт
Метод для системи, якою досі користуються.
Проведено як оплачений R&D-проєкт під час попередньої співпраці засновника, з правом пропонувати ту саму спроможність через Cloverity. Технічна основа: Python із FastAPI, асинхронний SQLAlchemy, pytest і React на фронтенді; карта залежностей — через графову кластеризацію; сама міграція — агентами Claude Code під керуванням інженерів.
Результати
Що саме було виміряно.
Це цифри самого R&D-запуску — виміряні, а не змодельовані. Ми не публікуємо того, чого не рахували.
44 000
рядків legacy-коду, розкладених на карту й упорядкованих у 14 юнітів
11 із 14
юнітів перенесено — 79% системи, на цьому ми зупинилися
918+
тестів написано, щоб зафіксувати поведінку до і після переносу кожного юніта
576+
надлишкових запитів до бази прибрано під час перебудови шару даних
Чого ми не вимірювали: витрачений час, зекономлені гроші чи рядки на день. Такі цифри є в багатьох презентаціях про міграції; ми їх тут не рахували — тому й не наводимо.
Є система, до якої ніхто не хоче торкатися?
Розкажіть про неїЩо ми робимо для клієнта
Те, що з цього переходить у клієнтські проєкти.
R&D був репетицією. У реальний проєкт ми беремо метод, а не кодову базу.
Спочатку карта, потім рух
Ми починаємо з карти залежностей наявної системи й перетворюємо її на впорядкований список юнітів. Саме цей порядок відрізняє поетапну міграцію від каскаду поломок — і він же показує, ще до першого перенесеного рядка, який реальний обсяг роботи попереду.
Спершу тести — щоб поведінку можна було довести
Навколо кожного юніта пишуться характеризаційні тести на його поточну поведінку ще до того, як його чіпають. Після переносу ті самі тести мають проходити. Саме це дозволяє перевірити міграцію тому, кого не було в кімнаті.
Система лишається доступною
Публічний інтерфейс тримається стабільним, поки всередині все змінюється, — тож суміжні системи продовжують працювати, і бізнесу не треба планувати «темний період». Можна зупинитися між юнітами й усе одно мати робочу систему.
Агенти беруть обсяг, люди задають напрям
AI-агенти виконують механічну масу переносу — у визначеному порядку й під тестовим гейтом. Послідовність, архітектурні рішення та рев'ю лишаються за інженерами. Саме тому результат можна перевірити.
Обсяг, послідовність і трудомісткість для вашої системи виходять із кроку картування, а не з шаблону — тому перше, що ми робимо в реальному проєкті, це вимірюємо вашу кодову базу.
Переписування з нуля — це єдиний варіант, який зараз на столі?
Опишіть форму системи: мова, приблизний розмір і що ламається найчастіше. Ми повернемося з тим, як саме склали б карту й послідовність, і з чесною відповіддю, чи поетапна міграція взагалі ваш випадок.