AI против легаси: эксперимент на реальном проекте
На Хабре вышла моя новая статья! 🚀
В прошлый раз я рассказывала, как мы с командой выстраивали работу с техническим долгом. Теперь решила продолжить тему и показать, как мы подключили к этому процессу AI - через набор специализированных skills: для тестов, выделения хуков и утилит, разделения компонентов, миграций и проверки изменений.
Сверху добавили скилл-оркестратор, который анализирует компонент и решает, что действительно нужно рефакторить, а что лучше не трогать.
И конечно, проверили подход — на 36 компонентах и собрали метрики. Получилось ли реально ускорить работу или просто добавили ещё один слой сложности? Результаты, примеры скиллов и наши грабли — в статье 👇
https://habr.com/ru/companies/sovcombank_technologies/articles/1097382/
· вчера
У оркестратора здесь интересен критерий «лучше не трогать»: размер компонента сам по себе ещё не показывает пользу рефакторинга. Вы отдельно оценивали случаи, когда он отказался от изменений, и стоимость проверки результата человеком — или метрики на 36 компонентах пока относятся только к выполненным преобразованиям?
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён
· вчера
У нас была немного другая постановка задачи: мы заранее определили объём миграции и хотели довести её до конца, поэтому изменения прошли все 36 компонентов. Размер компонента не был критерием отбора. Оркестратор выбирал необходимые преобразования для каждого компонента: где-то требовалась только замена стилей, где-то - ещё вынос логики и миграция запросов.
Поэтому эта выборка не позволяет оценить критерий «лучше не трогать» - такого решения на уровне компонента в нашей задаче не предполагалось. А стоимость проверки человеком отдельно не замеряли, и это действительно стоит учесть в следующих измерениях.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён