GlowByte — российский интегратор, специализирующийся в том числе на системах управления рисками. Один из разработчиков практики Risk & Compliance описал подход к бэкенд-разработке на Spring Boot, где объём шаблонного кода грозил съесть значительную часть времени команды.
Проект представлял собой backend API для системы принятия решений — класса ПО, которое в реальном времени обрабатывает множество входных параметров и выдаёт сложные бизнес-решения: оценку риска, предстраховые проверки, расчёт резервов. На входе у команды была OpenAPI-спецификация примерно на 100 подробно описанных REST-эндпоинтов, несколько сотен DTO, модель данных из 50+ таблиц и около десятка интеграций — аутентификация, VCS, обмен с базой через Apache NiFi, отдельный микросервис для тяжёлых вычислений. Бизнес-требования при этом уточнялись по ходу разработки, что делало раннее покрытие тестами нецелесообразным.
| Инструмент | Задача | Ключевой эффект |
|---|---|---|
| OpenAPI Generator | Генерация DTO, enum'ов, интерфейсов контроллеров из спецификации | Контракт API в одном месте; несоответствия видны на этапе компиляции |
| QueryDSL | Динамические типобезопасные запросы к БД | Ошибки при переименовании полей обнаруживаются компилятором, код читаемее Criteria API |
| ChatGPT (5.2 / 5.4) | Генерация unit- и интеграционных тестов | ~5–7% тестов требовали правки; эффективен при наличии JavaDoc и стабильной бизнес-логике |
Первым инструментом стал OpenAPI Generator. Вместо того чтобы вручную переносить из спецификации все эндпоинты, DTO и enum'ы в Java-код, команда настроила генерацию: из YAML-описания автоматически создавались классы DTO, интерфейсы API, методы контроллеров с заданными сигнатурами и Swagger-документацией. Ключевой эффект — контракт API жил в одном месте. Если аналитик менял поле или тип в спецификации, несоответствие всплывало на этапе генерации или компиляции, а не обнаруживалось вручную при сравнении документации и кода.
OpenAPI Generator автоматически создавал DTO, enum'ы и интерфейсы контроллеров из спецификации, устраняя ручную синхронизацию.
Вторым инструментом стал QueryDSL — библиотека для построения типобезопасных запросов к базе данных. В проекте было много сложных запросов с динамической фильтрацией: по статусу, диапазону дат, идентификатору исполнителя. Стандартный Criteria API справляется с такими задачами, но код получается громоздким и плохо читаемым. QueryDSL позволяет записать тот же запрос декларативно: `predicate.and(task.status.eq(status))` вместо `criteriaBuilder.equal(root.get("status"), status)`. При переименовании поля в модели компилятор сразу укажет на проблему — в отличие от строкового JPQL, где ошибка проявится только в рантайме. Автор отмечает, что при использовании `Projections.constructor` порядок и типы параметров проекции всё равно нужно контролировать вручную.
Третьим инструментом стал ChatGPT — сначала версии 5.2, затем 5.4. Тесты писались после стабилизации основных пользовательских сценариев: покрывать нестабильный код на ранней стадии, когда сигнатуры и бизнес-правила ещё меняются, команда сочла нецелесообразным. Рабочий сценарий промптинга выглядел так: сначала в контекст подавался код тестируемого класса, начиная с нижних уровней абстракции, затем добавлялись DTO, enum'ы и зависимости. Наличие JavaDoc-комментариев к методам существенно упрощало промпт. После получения результата разработчик проверял, не является ли сгенерированный тест «синтетикой», при необходимости запрашивал дополнительные edge cases, запускал тесты и разбирался с непрошедшими — их оказалось около 5–7%. Ограничение модели проявилось примерно на 30% от лимита токенов: она начинала «забывать» код, уже находившийся в контексте, и его приходилось дублировать. Принципиальной разницы между версиями 5.2 и 5.4 автор не заметил.
Опыт команды показывает типичную для зрелых проектов расстановку приоритетов: автоматизация рутины там, где контракт стабилен (генерация из спецификации), типобезопасность там, где логика сложна (динамические запросы), и отложенное тестирование там, где требования ещё не устоялись. ИИ-ассистент при этом выступает инструментом ускорения, а не заменой разработчика — особенно когда речь идёт об объёмном контексте и нетривиальной бизнес-логике.