Александр, Java-разработчик практики Risk & Compliance в GlowByte, опубликовал на Хабре разбор реального backend-проекта на Spring Boot - с сотней REST-эндпоинтов, полусотней таблиц и разветвлённой бизнес-логикой. Главный вопрос: как не утонуть в бойлерплейте, когда ТЗ ещё дышит и меняется.
Контракт живёт в одном месте
Первым инструментом в связке стал OpenAPI Generator. Спецификация на сотню подробно описанных эндпоинтов уже существовала - переносить её вручную в Java-классы было бы просто расточительством. Генератор взял на себя DTO, енамы, интерфейсы контроллеров и сигнатуры методов с документацией. Разработчику оставалась реализация.
Главный практический эффект - синхронность. Если аналитик поменял тип поля или переименовал эндпоинт в спецификации, это выплывает на этапе генерации или компиляции, а не в момент, когда фронт уже ждёт ответа. Александр добавляет с иронией: заодно проще перекладывать ответственность за ошибки на того, кто описывал спецификацию.
Типобезопасность вместо строкового JPQL
Вторая проблема - динамические запросы. Проект требовал гибкой фильтрации с десятком необязательных параметров. Строковый JPQL здесь небезопасен, Criteria API - читается с трудом. QueryDSL занял середину: декларативный синтаксис, типобезопасность, ошибки переименования полей ловит компилятор, а не база данных в продакшне.
Вместо многословных конструкций Criteria API с criteriaBuilder.and и root.get код сводится к лаконичным predicate.and(task.status.eq(status)) - логика фильтров читается как текст. Оговорка одна: при использовании Projections.constructor порядок и типы параметров DTO-проекции нужно контролировать вручную, генератор здесь не страхует.
LLM как напарник по тестам, а не замена разработчика
Покрытие тестами намеренно отложили до стабилизации основных сценариев - пока модель данных и бизнес-правила активно менялись, массовое написание unit-тестов давало низкий ROI. После стабилизации подключили ChatGPT. Александр подчёркивает: речь именно о помощнике при объёмном контексте, а не об автопилоте.
Рабочий сценарий строился снизу вверх: сначала тестируемый класс с javadoc-описаниями методов, затем зависимости и DTO, затем уточняющий диалог с моделью. Примерно 5-7% сгенерированных тестов не проходили и требовали ручного разбора. Остальное после правки компиляционных ошибок работало. Итог - существенное ускорение покрытия без претензий на то, что инструмент думает за команду.
