Добрый день, уважаемый читатель Хабра! Меня зовут Вартанян Артур, и я являюсь Java-разработчиком в компании “Рексофт”. Совсем недавно мне под руку попался плагин, который помогает генерировать код при написании программ - это JPA Buddy. В этой статье я не буду транслировать официальную документацию проекта или показывать на примере видеороликов, как нужно с ним работать, а приведу примеры своих рабочих кейсов, где плагин действительно выручил и сэкономил мое время. Спойлер: в создании POJO-классов, репозиториев для тучи сущностей, DTO-классов. Если Вы опытный разработчик, которому часто приходится работать с сущностями, писать для них POJO-классы, используя при этом Spring Boot и Spring Data JPA, то эта статья будет полезной. Я бы не советовал пользоваться плюшками данного плагина начинающему разработчику, так как JPA Buddy генерирует большое количество кода и помогает собирать программу на начальном этапе как детский конструктор, что делает некоторые важные базовые процессы для новичка непрозрачными и мотивирует его не тратить время на их изучение. Совсем недавно я спроектировал достаточно нестандартное WEB MVC-приложение. Оно должно было выступить у меня в роли pet-project’а для работы с новыми библиотеками и решениями. Нестандартно оно тем, что имеет в себе большое количество сущностей и соответствующее количество слоев для каждой сущности, то есть, имея 15 сущностей, мне нужно было создать как минимум 15:   POJO-классов и сделать разметку для ORM; Репозиториев для работы с JPA; Сервисов для бизнес-логики; DTO-классов; Rest-контроллеров для работы с сервисами  ; SQL-скриптов для FlyWay миграций. Вы спросите меня, по какой причине мне пришлось громоздить столько сущностей с таким количеством сервисов и контроллеров, и почему я не разработал уровень абстракции, который помог бы избежать большого количества кода? Любая абстракция со временем может начать проседать, так как приложение становится все больше и больше, и не всегда получается вписываться в рамки "обобщений". Поэтому тут выбор между: большим количеством кода (то есть временем его написания и трудоемкостью дальнейшей поддержки) и созданием абстракций, которые в дальнейшем придется "покрывать костылями", если вдруг окажется, что она не слишком хороша. Как по мне, так в первом варианте преимуществ больше. Да и случаев, когда выбор идет в сторону большого количества кода, прилично. Уверен, что найдутся те, кто не согласятся -  понимаю и принимаю. Но это не повод не поделится моим опытом для тех, кому интересен JPA Buddy. Так что поехали.  После создания 3-го POJO-класса я понял, чтобы полностью расписать CRUD-методы приложения, придется потратить очень много времени, причем оно будет протекать максимально медленно, ведь работа в основном рутинная. Так было бы, если Intellij Idea в какой-то момент не порекомендовала мне включить плагин JPA-Buddy, который долгое время лежал у меня без дела. Вся прелесть данного плагина в том, что он без труда покрывает 4 из 6 проблемных пункта, которые я описал выше. А именно: Создание POJO-классов: Есть два пути создания POJO-классов через плагин: Генерация из уже существующих таблиц. Генерация через UI, где мы можем указывать только названия полей и их типы (при этом в один клик добавляя нужные аннотации). Мне сильно повезло, ведь я как “добросовестный программист” собрал базу данных вручную, и она уже была готова. Затем я воспользовался быстрой генерацией, исходя из таблиц БД, и за минуту все 15 классов были созданы и помечены аннотациями для ORM. Создание репозитория для каждой сущности: Плагин также поддерживает генерацию репозиториев. Все что нужно - это указать сущность, для которой мы генерируем репозиторий, название репозитория и тип репозитория из целого списка (пример CrudRepository или JpaRepository). Создание DTO-классов: Логика абсолютно такая же, как и в предыдущих действиях. Создаем DTO, указываем исходный класс, даем название новому классу и выбираем нужные поля для трансфера. Одно из самых больших преимуществ - это поддержка библиотеки MapStruct, которая выступает в роли маппера. Достаточно добавить ее зависимости к себе в проект, и при последующем создании DTO у вас высветится поле с явным созданием маппера. Создание FlyWay миграций, исходя из существующих классов: В целом JPA-Buddy предоставляет обширный круг возможностей для работы с миграциями: создание Java-миграций, генерация SQL-скриптов, JSon-представлений для баз данных и т.д. Например, создав пустой файл с .sql расширением, можно автоматически генерировать скрипты для таблиц, колонок и индексов.   JPA-Buddy действительно мощный инструмент, который заметно облегчает жизнь разработчику, избавляя его от рутинной работы, не считая того, что был рассмотрен далеко не весь функционал плагина. Для меня в первую очередь - это экономия времени и возможность за короткий срок собрать решение, если под рукой отсутствует ready-made-solution. Спасибо за внимание! Надеюсь данная статья была полезна для вас! Разработчик