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 решает эту боль просто: каждому входящему запросу выдаётся уникальный идентификатор, который потом проходит через логи, заголовки и внутренние вызовы. В итоге можно быстро найти весь путь конкретного запроса: • где он пришёл • какой сервис его обработал • на каком шаге появилась...