Во-первых, мы тоже часто задаёмся таким вопросом.
Во-вторых, может просто разработчики не в курсе, что их код немного мёртв...
Проверяя микросервис после миграции на Java 17 и Spring Boot 3, я вдруг обнаружил полностью пустую БД. Выполнение такой задачи человеком, не имеющим никакого отношения к созданию и поддержке функционала, является хорошим началом для увлекательной истории.
Приложение, которое не хочет стартовать без подключения, но при этом и не создает ни одного объекта, выглядело очень подозрительным. В pom.xml был и стартер для JPA, и дополнительные библиотеки для Hibernate. В конфигурации путь до файла с журналом изменений Liquibase, который в свою очередь включал директорию с форматированными sql.
Запуск приложения в debug режиме бескомпромиссно сообщил, что LiquibaseAutoConfiguration не активен из-за отсутствия класса liquibase.change.DatabaseChange. Да, набор pom.xml многомодульного проекта содержал многое, что-то умудрялись объявить два, а то и три раза. Но вот org.liquibase:liquibase-core среди всего этого не завалялось.
Первой мыслью было, что зависимость либо удалили, либо случайно потеряли на каком-то разрешении конфликтов. Добавил артефакт, пересобрал, запустил и получил ошибку liquibase.exception.ChangeLogParseException: classpath:/db.changelog/master.yaml does not exist.
Знаете, как InteliiiJ IDEA вложенные директории объединяет через точку, чтобы не плодить лишние уровни в интерфейсе структуры проекта? Вот это было очень похоже на причину ошибки в конфигурации микросервиса, которая спрятала нужный ресурс в db/changelog. Кто-то набрал текст, ориентируясь сугубо на надпись в интерфейсе.
Удивлением номер два стало, что настройки созданы еще в мае прошлого года и за прошедшие 10 месяцев не менялись. При этом миграции были дополнены несколькими новыми sql-скриптами полтора и два месяца назад. То есть миграции гарантированно не работали изначально, и потом их еще дважды дополняли наборами изменений схемы, но пустая база так никого и не смутила.
Последняя надежда оставалась на историю из серии “Открыть ворота! Закрыть ворота!”. Что-то реализовали, потом решили отказаться, но не торопились убирать мертвый код. Но реальность превзошла ожидания и тут, команда оказалась не в курсе проблемы.
Вот теперь думаю, как мне могут прокомментировать информацию, что контейнер сервлетов в веб-приложении с REST API добавляется только по причине подключения api-библиотеки, которая транзитивно добавляет другую api-библиотеку, а только она зачем-то сильно хочет Apache Tomcat.
Говорят, что во всём надо искать свои плюсы? Согласен. Теперь когда не работает какое-то приложение, я просто вспоминаю людей, которые могли успеть поучаствовать в его реализации…