Приходилось ли писать свои Spring стартеры
Что проверяют
Понимаете ли вы механизм автоконфигурации и знаете ли правила хорошего стартера.
Как отвечать
Стартер нужен, когда одна и та же обвязка повторяется в нескольких сервисах: настройка журналирования и трассировки, общий клиент к внутреннему сервису, схема аутентификации, обработка ошибок. Вместо копирования конфигурации в каждый проект подключается зависимость.
Как устроено:
- класс конфигурации с объявлением бинов;
- регистрация этого класса в файле списка автоконфигураций внутри ресурсов. В старых версиях для этого использовался другой файл, и это частая причина, почему стартер не подхватывается после обновления;
- условия подключения: бины создаются только если в пути классов есть нужная библиотека, если пользователь не объявил свой бин такого типа, если включён соответствующий параметр настройки;
- свойства через отдельный класс с привязкой к префиксу, чтобы всё настраивалось из общего файла конфигурации.
Правила, которые отличают хороший стартер:
- не навязывать: условие на отсутствие пользовательского бина обязательно, иначе переопределить поведение станет невозможно;
- выключаемость: параметр включения с разумным значением по умолчанию;
- не тянуть лишние зависимости и помечать необязательные как таковые;
- осмысленное именование по принятому соглашению, чтобы стартер не путали с официальным;
- документация свойств: генерация подсказок для среды разработки делается автоматически.
Тестируют такие модули специальным средством, позволяющим поднять контекст с разными наборами условий и проверить, какие бины появились, а какие нет. Это быстрее полноценного приложения.
Подводные камни: порядок применения автоконфигураций, конфликты версий зависимостей у потребителей, и соблазн сложить в один стартер всё сразу вместо нескольких маленьких.
Где спотыкаются
Регистрируют конфигурацию в устаревшем файле и не понимают, почему она не работает.
Не ставят условие на отсутствие пользовательского бина.
Собирают один большой стартер на все случаи.
Тянут за собой тяжёлые зависимости, ломая сборку потребителей.