Java

Когда в коде встречается 86400, 7, 1.21 или 5000, компилятору всё равно. Человеку - нет. Через месяц уже приходится вспоминать, что это было: секунд в дне, дней сессии, НДС или задержка перед повторной попыткой. Плохой вариант выглядит так: if (sessionAgeSeconds > 86400 * 7) Формально код работает. Но смысл спрятан внутри чисел. Нормальный вариант: SECONDS_PER_DAY SESSION_DAYS VAT_RATE RETRY_DELAY_MS Теперь намерение видно прямо в месте вызова. Не нужно угадывать, почему именно 7, что означает 5000 и можно ли безопасно поменять значение...

В switch expression начиная с Java 14+ компилятор проверяет, что обработаны все возможные значения. Если у вас enum и вы забыли один из вариантов, код просто не соберётся. Это даёт сразу несколько плюсов: - меньше скрытых багов после рефакторинга - безопаснее расширять enum - компилятор...

Если обычного return user уже мало, в Spring Boot есть ResponseEntity<T>. Он позволяет явно управлять всем ответом: • статусом HTTP • заголовками • телом ответа • обработкой ошибок • поведением API в нестандартных сценариях Пример: пользователь найден - возвращаем 200 OK, тело ответа и кастомный header. Пользователь не найден - возвращаем 404 NOT FOUND без лишней магии...

В Java @Override - это не украшение над методом, а простая защита от глупых ошибок. Представь базовый класс: class Report { void print() { // ... } } Ты хочешь переопределить метод, но случайно пишешь prnt() вместо print(): class PDFReport extends Report { void prnt() { // ... } } Код скомпилируется. Но метод print() не переопределён. Ты просто создал новый метод с опечаткой, а старое поведение осталось на месте...

Когда API начинает сыпаться ошибками, главный вопрос не «что сломалось», а «где именно сломалось». Request ID решает эту боль просто: каждому входящему запросу выдаётся уникальный идентификатор, который потом проходит через логи, заголовки и внутренние вызовы. В итоге можно быстро найти весь путь конкретного запроса: • где он пришёл • какой сервис его обработал • на каком шаге появилась...

В 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...

@ConditionalOnClass - одна из тех аннотаций, из-за которых Spring Boot кажется умным. Она говорит фреймворку: «Включи этот bean или конфигурацию только если нужный класс реально есть в проекте». Простой пример: @Configuration @ConditionalOnClass(DataSource.class) public class DataSourceAutoConfiguration { // загружается только если доступен javax.sql.DataSource } То есть Spring Boot не пытается настраивать всё подряд. Он смотрит: • есть ли нужная библиотека в зависимостях...

Классический сценарий: Вы грузите список заказов: orderRepository.findAll() А потом в цикле обращаетесь к order.getItems(). Hibernate сначала делает один запрос за заказами, а потом ещё по одному запросу на каждый заказ, чтобы достать items. 100 заказов = 101 SQL-запрос. И вот здесь спасает @EntityGraph. Он позволяет явно сказать репозиторию, какие связи нужно подтянуть сразу: @EntityGraph(attributePaths = {"items"}) В итоге Hibernate может сгенерировать один запрос с JOIN, вместо десятков лишних походов в базу...

Если у вас есть scheduled task, не стоит хардкодить интервал прямо в аннотации: `@Scheduled(fixedRate = 5000)` Лучше вынести значение в конфиг: `@Scheduled(fixedRateString = "${task.interval}")` А в application.properties указать: `task.interval=5000` Почему так лучше: •...

Если frontend и backend живут на разных доменах или портах, браузер начнет резать запросы по CORS. Это не баг Spring Boot и не проблема React. Это нормальный механизм безопасности браузера. Правильный способ - настроить CORS на стороне backend. В Spring Boot это можно сделать глобально через WebMvcConfigurer: указать маршруты, разрешенные origins, HTTP-методы, заголовки и работу с credentials. Главное - не ставить бездумно * везде подряд, особенно если используете cookies, токены или allowCredentials(true)...

В Spring Boot не стоит бездумно писать что-то вроде: @ComponentScan("com.mycompany") На первый взгляд удобно: фреймворк сам просканирует весь пакет и найдет нужные компоненты. Но проблема в том, что он может просканировать слишком много. Это увеличивает время classpath scanning, замедляет старт приложения и иногда подтягивает классы, которые вообще не должны были становиться Spring-компонентами. Лучший вариант - полагаться на дефолтное поведение: @SpringBootApplication...

Классика: приходит запрос с дополнительным полем, которого нет в DTO и ты ловишь UnrecognizedPropertyException. Клиент добавил поле, ты не обновил модель - всё падает. Решение в одну строку: @JsonIgnoreProperties(ignoreUnknown = true) public...