⚡️ Перестаём писать методы с 7+ параметрами

Если сигнатура выглядит как:

createUser(firstName, lastName, email, phone, address, city, country)

Это уже сигнал, что модель данных развалилась.

Проблема не только в читаемости.
Такие методы сложнее поддерживать, расширять и тестировать. Любое изменение ломает сигнатуру и тянет за собой каскад правок.

Нормальный вариант - собрать связанные данные в объект:

UserInfo userInfo

Получаем:

- чище API
- проще добавлять поля
- меньше ошибок при передаче параметров
- код начинает отражать доменную модель, а не список строк

Это базовый приём, но именно на нём чаще всего экономят, а потом платят сложностью.

Небольшой, но полезный совет для Spring Boot.

Если у вас есть scheduled task, не стоит хардкодить интервал прямо в аннотации:

`@Scheduled(fixedRate = 5000)`

Лучше вынести значение в конфиг:

`@Scheduled(fixedRateString = "${task.interval}")`

А в application.properties указать:

`task.interval=5000`

Почему так лучше:

• интервал можно менять без правки кода;
• настройки проще различать для dev, staging и production;
• меньше магических чисел в бизнес-логике;
• конфигурация становится прозрачнее.

Мелочь, но именно из таких мелочей и складывается нормальная поддерживаемость Spring Boot-проекта.

N+1 в Spring Boot выглядит безобидно, пока прод не начинает молиться на базу данных.

Классический сценарий:

Вы грузите список заказов:

orderRepository.findAll()

А потом в цикле обращаетесь к order.getItems().

Hibernate сначала делает один запрос за заказами, а потом ещё по одному запросу на каждый заказ, чтобы достать items.

100 заказов = 101 SQL-запрос.

И вот здесь спасает @EntityGraph.

Он позволяет явно сказать репозиторию, какие связи нужно подтянуть сразу:

@EntityGraph(attributePaths = {"items"})

В итоге Hibernate может сгенерировать один запрос с JOIN, вместо десятков лишних походов в базу.

Что получаем:

- меньше SQL-запросов
- меньше нагрузки на БД
- чище код репозитория
- без ручного JPQL
- fetch-стратегия управляется точечно под конкретный кейс

LAZY сам по себе не зло. Зло - когда вы не контролируете, где и как он срабатывает.

@EntityGraph - один из самых простых способов держать N+1 под контролем в Spring Boot.

Spring Boot: уберите try/catch из контроллеров

В Spring Boot не нужно размазывать обработку ошибок по каждому endpoint через бесконечные try/catch.

Для этого есть @RestControllerAdvice.

Идея простая: вы выносите обработку исключений в один глобальный класс, а контроллеры оставляете чистыми.

Например:

@RestControllerAdvice
public class GlobalExceptionHandler {

    @ExceptionHandler(ResourceNotFoundException.class)
    public ResponseEntity<?> handleNotFound(ResourceNotFoundException ex) {
        return ResponseEntity
                .status(HttpStatus.NOT_FOUND)
                .body(new ErrorResponse("NOT_FOUND", ex.getMessage()));
    }

    @ExceptionHandler(IllegalArgumentException.class)
    public ResponseEntity<?> handleBadRequest(IllegalArgumentException ex) {
        return ResponseEntity
                .badRequest()
                .body(new ErrorResponse("BAD_REQUEST", ex.getMessage()));
    }

    @ExceptionHandler(Exception.class)
    public ResponseEntity<?> handleGeneric(Exception ex) {
        return ResponseEntity
                .status(HttpStatus.INTERNAL_SERVER_ERROR)
                .body(new ErrorResponse("INTERNAL_ERROR", "Something went wrong"));
    }
}

После этого контроллер может выглядеть спокойно:

@GetMapping("/users/{id}")
public User getUser(@PathVariable Long id) {
    return userService.findById(id);
}

Если пользователь не найден - сервис кидает ResourceNotFoundException, а Spring сам отправит нормальный 404.

Что это даёт:

• меньше мусора в контроллерах
• единый формат ошибок
• проще поддерживать API
• легче логировать исключения
• меньше копипасты в endpoint-ах

Контроллер должен описывать сценарий запроса, а не превращаться в свалку обработки ошибок.

Твой код — в сердце мощного ИИ! 💚

Команда GigaChat зовёт на One Day Offer амбициозных Java-разработчиков, которые готовы создавать AI‑продукты уровня BigTech и стать частью крупнейшего AI-комьюнити.

Если ты дружишь с Java (версии 8–25), ладишь со Spring и Hibernate, а PostgreSQL и ClickHouse для тебя — не просто слова, переходи по ссылке и занимай слот на One Day Offer.

Встречаемся 23 мая — очень ждём именно тебя!

N+1 в Spring Boot выглядит безобидно, пока прод не начинает молиться на базу данных.

Классический сценарий:

Вы грузите список заказов:

orderRepository.findAll()

А потом в цикле обращаетесь к order.getItems().

Hibernate сначала делает один запрос за заказами, а потом ещё по одному запросу на каждый заказ, чтобы достать items.

100 заказов = 101 SQL-запрос.

И вот здесь спасает @EntityGraph.

Он позволяет явно сказать репозиторию, какие связи нужно подтянуть сразу:

@EntityGraph(attributePaths = {"items"})

В итоге Hibernate может сгенерировать один запрос с JOIN, вместо десятков лишних походов в базу.

Что получаем:

- меньше SQL-запросов
- меньше нагрузки на БД
- чище код репозитория
- без ручного JPQL
- fetch-стратегия управляется точечно под конкретный кейс

LAZY сам по себе не зло. Зло - когда вы не контролируете, где и как он срабатывает.

@EntityGraph - один из самых простых способов держать N+1 под контролем в Spring Boot.

📌 Magic numbers в Java - мелкая привычка, которая потом превращает поддержку кода в археологию.

Когда в коде встречается 86400, 7, 1.21 или 5000, компилятору всё равно. Человеку - нет. Через месяц уже приходится вспоминать, что это было: секунд в дне, дней сессии, НДС или задержка перед повторной попыткой.

Плохой вариант выглядит так:

if (sessionAgeSeconds > 86400 * 7)

Формально код работает. Но смысл спрятан внутри чисел.

Нормальный вариант:

SECONDS_PER_DAY
SESSION_DAYS
VAT_RATE
RETRY_DELAY_MS

Теперь намерение видно прямо в месте вызова. Не нужно угадывать, почему именно 7, что означает 5000 и можно ли безопасно поменять значение.

Это особенно важно в бизнес-логике, где числа редко бывают случайными. Лимиты, комиссии, таймауты, скидки, сроки жизни сессии, количество попыток - всё это правила продукта, а не просто цифры в коде.

Хорошее правило простое: если число несёт смысл, дай ему имя. Исключения вроде 0, 1, индексов и простых счётчиков можно не трогать.

Чистый код часто начинается не с архитектуры, а с таких скучных вещей: убрать загадочные числа и оставить будущему разработчику понятный контекст.

#java #cleancode