Почему отказались от описания DTO через YAML файлы
Что проверяют
Понимаете ли вы разницу между схемой контракта и кодом, и можете ли обосновать отказ от инструмента опытом, а не вкусом. За вопросом почти всегда стоит история проекта: DTO генерировались из спецификации в YAML, от этого ушли к рукописным классам, и интервьюер хочет услышать, какие именно неудобства перевесили.
Как отвечать
Сначала развести два разных сценария, их постоянно смешивают:
- спецификация OpenAPI или AsyncAPI в YAML плюс генератор, который на этапе сборки делает из неё Java-классы;
- YAML как формат конфигурации, который парсится в объект уже в рантайме.
Вопрос обычно про первый. Типичные причины отказа: генератор диктует форму классов, и любая мелочь правится шаблонами, а не кодом; сгенерированные DTO неудобно дополнять валидацией и аннотациями сериализации; обновление генератора ломает сборку на ровном месте; по сгенерированному коду тяжело ходить отладчиком, а ревью правки спецификации не показывает, что изменилось в классах.
Сильный ответ заканчивается ценой решения: что было, что заболело, что сделали и чем платите сейчас. Отказавшись от генерации, вы теряете единый источник правды, и спецификацию приходится либо писать руками, либо собирать из кода. Если контракт публичный или его читают соседние команды, генерация обычно остаётся, а меняется только то, что генерируется.
Где спотыкаются
Сводят всё к тому, что YAML нетипизирован. Схема как раз описывает типы, и несоответствие ловится на генерации, а не в рантайме. Настоящая боль не в типизации, а в навязанной форме классов и в связке со сторонним генератором.
Говорят про накладные расходы на разбор YAML. При кодогенерации файл читается один раз при сборке и в рантайм не попадает вовсе, так что довод про производительность просто не про этот случай.
Отвечают «стало неудобно», без критерия. Интервьюер ждёт сравнения двух вариантов по одной шкале: сколько людей читает контракт, как часто он меняется, кто ломается первым при расхождении. Без этого ответ звучит как вкусовщина.