От Java 8 до Spring Boot 3: как ИИ-помощник по программированию ускоряет обновление устаревших проектов на 50 %

Прошлой зимой я взял на себя устаревший проект, который был особенно проблематичным, используя Java 8 плюс Spring MVC с XML и кучу самоинкапсулируемых классов инструментов. Заказчик издал фатальный приказ о том, что он должен выполнить обновление до Spring Boot 3 в течение полугода, иначе все отчеты о сканировании безопасности будут содержать уязвимости высокого риска, и контракт не будет продлен. Никто в команде не хочет его трогать, опасаясь, что если они допустят ошибку, это вызовет ажиотаж в сети. Я стиснул зубы и узнал, что человек, который наконец помог мне, был помощником по программированию ИИ. Честно говоря, я сначала был в полной неуверенности. Для запуска Spring Boot 3 требуется Java 17 и Spring Framework 6. Многие старые API были либо удалены, либо их семантика была изменена. В проекте десятки тысяч строк кода в десятках классов, смешанных с различными пользовательскими конфигурациями и сторонними библиотеками. На ручную модификацию каждого уходит три месяца. Я решил попробовать ИИ, выбрал помощника по программированию, понимающего контекст, и начал миграцию. Сначала я попросил ИИ помочь мне прояснить структуру проекта, сообщить ему пути к pom.xml и нескольким основным файлам конфигурации, а также позволить ему проанализировать зависимости и методы запуска. ИИ быстро выдал список, указав, какие зависимости в Spring Boot 3 устарели, а какие необходимо заменить. Например, Springfox-swagger2 необходимо заменить на Springdoc-openapi. Это также напомнило мне, что пакет javax.servlet необходимо заменить на jakarta.servlet, а это самый простой и трудоемкий шаг. Преобразование кода — самый трудоемкий этап. Я попросил ИИ просканировать все классы контроллеров и сервисов, чтобы найти, где использовался старый API. Он может не только идентифицировать @Controller и @RequestMapping, но также определять, где используется javax.validation и где используются старые типы, такие как Date и Calendar. Я попытался заставить его автоматически генерировать коды замены, например, изменить javax.validation на jakarta.validation и Date на LocalDateTime. Точность ИИ меня очень удивила. Он может даже автоматически корректировать оператор импорта в соответствии с контекстом и даже решать общие проблемы, которые я обычно упускаю из виду. Конечно, ИИ не всемогущ. Однажды он неправильно изменил кастомный перехватчик, и проверка входа сразу провалилась. Я потратил день на расследование и, наконец, обнаружил, что ИИ записал неверный тип параметра в сигнатуру метода preHandle HandlerInterceptor. Это заставило меня понять, что ИИ — это помощник, а не замена. Он может выполнять повторяющиеся задачи очень быстро, но ключевая бизнес-логика все равно должна проверяться людьми. Я скорректировал свою стратегию и позволил ИИ сначала изменить чисто технический код, а затем позволить ему поработать над частью бизнес-логики после того, как я его просмотрю. Миграция профиля также вызывает у меня головную боль. Все файлы Spring-mvc.xml и applicationContext.xml в старом проекте необходимо преобразовать в application.yml. ИИ помог мне проанализировать определения компонентов в XML и сгенерировать соответствующие классы конфигурации Java. Например, если он изначально был определен с помощью класса bean id="dataSource", он автоматически преобразуется в метод @Bean, формат правильный, а значения атрибутов также перемещаются как есть. Это также помогло мне оптимизировать некоторые места, например извлечение жестко запрограммированной информации о подключении к базе данных в элементы конфигурации, что стало неожиданным преимуществом. Процесс тестирования еще более неотделим от ИИ. В старом проекте почти не было модульных тестов. Я попросил ИИ автоматически генерировать тесты для JUnit 5 на основе существующей логики кода.