Многие разработчики в принципе против использования Lombok. В общем, это холиварная тема. Но вы используете Lombok в проекте, то не используйте хотя бы спорные и откровенно вредные аннотации.
Одна из таких – это `@Data`. Во-первых,[мало кто помнит, что она под собой скрывает](https://projectlombok.org/features/Data).
-`@ToString`. Не помню, когда последний раз переопределял `toString()`. А если объект содержит чувствительную информацию?
-`@EqualsAndHashCode`. Это самая вредная аннотация в @Data.==Потому что она генерирует `equals()` и `hashCode()` по всем полям.== Обычно вы не хотите, чтобы генерация осуществлялась по всем полям. Например, для сущности достаточно идентификатора.
-`@Getter`/`@Setter`. Здесь ничего плохого.
-`@RequiredArgsConstructor`. Тоже окей.
Основная проблема в `@EqualsAndHashCode`. Можно, конечно, использовать `@EqualsAndHashCode.Exclude`. Эта аннотация запрещает использовать поле при генерации, но вы хотите расставлять это над почти всеми полями в сущности? Потому что `@EqualsAndHashCode.Include` просто не сработает, нельзя объявить только нужные поля, нужно будет именно исключать все ненужные.
Также избегайте всех аннотаций из пакета `experemental`. Все аннотации из этого пакета могут работать не стабильно, и при этом могут быть удалены из следующих версий. Исключением из этого пакета является [@FieldNameConstants](https://projectlombok.org/features/experimental/FieldNameConstants), за пару лет с ней не было никаких проблем, а все имеющиеся альтернативы не очень.
С Lombok код выглядит чище, но, как и в случае с любым другим магическим инструментом, важно понимать, как именно он работает и когда его использовать. В противном случае производительность приложения может снизиться, либо оно вовсе может перестать работать корректно.
## Дополнительные материалы
- [Lombok + JPA: Что может пойти не так? / Хабр](https://habr.com/ru/company/haulmont/blog/564682/)
