Compare commits

...

2 Commits

Author SHA1 Message Date
64ffad807c
SNAPSHOT версионирование.md
All checks were successful
continuous-integration/drone/push Build is passing
2024-10-02 22:13:34 +03:00
e8326a6711
Не используйте Data 2024-10-02 22:03:06 +03:00
3 changed files with 83 additions and 10 deletions

View File

@ -9,20 +9,19 @@ zero-link:
parents:
linked:
---
Многие разработчики в принципе против использования Lombok. В общем, это холиварная тема. Но вы используете Lombok в проекте, то не используйте хотя бы спорные и откровенно вредные аннотации.
Многие разработчики в целом против использования Lombok. Это действительно холиварная тема. Но если вы всё-таки используете Lombok в проекте, постарайтесь избегать спорных и потенциально вредных аннотаций.
Одна из таких это `@Data`. Во-первых, [мало кто помнит, что она под собой скрывает](https://projectlombok.org/features/Data).
Одна из таких — это `@Data`. Во-первых, мало кто помнит, [какие методы она генерирует](https://projectlombok.org/features/Data).
- `@EqualsAndHashCode`. Это наиболее проблемная аннотация в составе `@Data`. Она генерирует методы `equals()` и `hashCode()` для всех полей класса, но зачастую этого не требуется. Например, для сущностей достаточно сравнивать только по идентификатору.
- `@ToString`. Если объект содержит чувствительную информацию, этот метод может вывести её в лог, что небезопасно.
- `@Getter` / `@Setter`. Здесь проблем нет.
- `@RequiredArgsConstructor`. Тоже допустимо.
- `@ToString`. Не помню, когда последний раз переопределял `toString()`. А если объект содержит чувствительную информацию?
- `@EqualsAndHashCode`. Это самая вредная аннотация в @Data. ==Потому что она генерирует `equals()` и `hashCode()` по всем полям.== Обычно вы не хотите, чтобы генерация осуществлялась по всем полям. Например, для сущности достаточно идентификатора.
- `@Getter` / `@Setter`. Здесь ничего плохого.
- `@RequiredArgsConstructor`. Тоже окей.
Основная проблема кроется в аннотации `@EqualsAndHashCode`. Конечно, можно использовать `@EqualsAndHashCode.Exclude`, чтобы исключить отдельные поля из генерации, но вам придётся добавлять это почти ко всем полям. Использовать `@EqualsAndHashCode.Include` не получится — вы не можете включить только необходимые поля, придётся исключать все лишние.
Основная проблема в `@EqualsAndHashCode`. Можно, конечно, использовать `@EqualsAndHashCode.Exclude`. Эта аннотация запрещает использовать поле при генерации, но вы хотите расставлять это над почти всеми полями в сущности? Потому что `@EqualsAndHashCode.Include` просто не сработает, нельзя объявить только нужные поля, нужно будет именно исключать все ненужные.
Кроме того, избегайте аннотаций из пакета `experimental`. Эти аннотации нестабильны и могут быть удалены в следующих версиях Lombok. Единственным исключением является [@FieldNameConstants](https://projectlombok.org/features/experimental/FieldNameConstants). За несколько лет с ней не возникало проблем, а существующие альтернативы оставляют желать лучшего.
Также избегайте всех аннотаций из пакета `experemental`. Все аннотации из этого пакета могут работать не стабильно, и при этом могут быть удалены из следующих версий. Исключением из этого пакета является [@FieldNameConstants](https://projectlombok.org/features/experimental/FieldNameConstants), за пару лет с ней не было никаких проблем, а все имеющиеся альтернативы не очень.
С Lombok код выглядит чище, но, как и в случае с любым другим магическим инструментом, важно понимать, как именно он работает и когда его использовать. В противном случае производительность приложения может снизиться, либо оно вовсе может перестать работать корректно.
В целом, Lombok делает код чище, но, как и с любым “магическим” инструментом, важно понимать, как он работает и в каких случаях его применение уместно. В противном случае это может привести к снижению производительности или даже некорректной работе приложения.
***
## Мета информация
**Область**:: [[../../meta/zero/00 Java разработка|00 Java разработка]]

View File

@ -0,0 +1,70 @@
---
aliases:
tags:
- maturity/🌱
date: 2024-10-02
zero-link:
parents:
linked:
---
В Maven проекте версия указывается в файле `pom.xml`. Если нужно указать, что версия артефакта является временной, вы добавляете суффикс `-SNAPSHOT` к номеру версии. Пример:
```
<version>1.0.0-SNAPSHOT</version>
```
Эта строка указывает, что артефакт находится в стадии разработки и может изменяться перед выпуском финальной версии.
## Механизм обновления SNAPSHOT-версий
SNAPSHOT-версии в Maven хранятся в центральном или локальном репозитории сборки и могут обновляться без изменения самой версии. Когда проект компилируется и отправляется в репозиторий, создается новая сборка с тем же номером версии, но внутри репозитория добавляются уникальные метаданные для отслеживания изменений. Эти метки времени позволяют Maven различать разные сборки SNAPSHOT, даже если версия формально остаётся той же.
Пример метаданных SNAPSHOT-версии: 1.0.0-20231002.123456-1 (где дата и уникальный идентификатор сборки указаны в имени файла).
Maven проверяет наличие обновлений для SNAPSHOT-версий каждый раз при сборке, если это явно указано в конфигурации. В зависимости от настроек, Maven может кешировать SNAPSHOT на некоторое время, чтобы не загружать каждый раз новую версию, или, наоборот, всегда загружать актуальную.
Настройка поведения обновления SNAPSHOT может быть указана в файле settings.xml или в конфигурации репозиториев в pom.xml.
```xml
<repository>
<id>my-repo</id>
<url>http://myrepo.com/maven2</url>
<snapshots>
<enabled>true</enabled>
<updatePolicy>always</updatePolicy>
</snapshots>
</repository>
```
Здесь `updatePolicy` может принимать следующие значения:
- `always`: Maven будет всегда проверять наличие новой SNAPSHOT-версии.
- `daily`: Проверка новых версий один раз в день.
- `interval:X`: Проверка новых версий каждые X минут.
- `never`: Maven не будет проверять новые версии, используя кешированные данные.
По умолчанию Maven хранит скачанные SNAPSHOT-версии в локальном репозитории (`~/.m2/repository`), и это может вызвать проблемы с устаревшими зависимостями. Если в репозитории была опубликована новая версия, а у вас в кэше осталась старая, это может вызвать ошибки. Чтобы избежать таких ситуаций, можно использовать команду `mvn clean install -U`, которая принудительно обновляет SNAPSHOT-зависимости из удалённого репозитория.
Если вы используете внешний репозиторий для хранения SNAPSHOT-версий, в pom.xml это можно указать следующим образом:
```xml
<repositories>
<repository>
<id>snapshot-repo</id>
<url>http://repository.example.com/snapshots</url>
<snapshots>
<enabled>true</enabled>
</snapshots>
</repository>
</repositories>
```
***
## Мета информация
**Область**:: [[../../meta/zero/00 Maven|00 Maven]]
**Родитель**:: [[SNAPSHOT версионирование|SNAPSHOT версионирование]]
**Источник**::
**Создана**:: [[2024-10-02]]
**Автор**::
### Дополнительные материалы
-
### Дочерние заметки
<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->

View File

@ -41,3 +41,7 @@ linked:
### Дочерние заметки
<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
<!-- SerializedQuery: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
- [[SNAPSHOT версионирование в Maven]]
<!-- SerializedQuery END -->