Войти в Y_LAB | IT развитие и юмор

Новый пост Y_LAB Actual | Код под микроскопом

Продолжаем рубрику, в которой разбираем реальные инженерные ситуации и ищем причины проблем, которые не всегда очевидны на первый взгляд.
Сегодня под микроскопом — equals() и hashCode() в Java

Представим класс пользователя:

class User {
private final String email;

public User(String email) {
this.email = email;
}

public String getEmail() {
return email;
}

@Override
public boolean equals(Object obj) {
if (this == obj) return true;
if (!(obj instanceof User)) return false;

User other = (User) obj;
return email.equals(other.email);
}
}

Здесь email объявлен как final. Для объектов, которые используются как ключи в hash-based коллекциях, неизменяемые поля, участвующие в equals() и hashCode(), значительно облегчают жизнь.
Иначе можно получить ещё одну неприятную ситуацию: объект уже добавлен в HashSet, но его поле, влияющее на хэш, изменилось, и коллекция больше не сможет найти его по новому или старому значению.

А теперь попробуем использовать User в HashSet:

Set<User> users = new HashSet<>();

users.add(new User("[email protected]"));

System.out.println(
users.contains(new User("[email protected]"))
);

Что выведет программа?

true?

Потому что у обоих объектов одинаковый email, а equals() считает их равными.

Но на самом деле результат будет

false

Почему так происходит?

HashSet использует не только equals(), но и hashCode().

Сначала коллекция определяет, в какую область поиска должен попасть объект, используя его хэш.
И только после этого при необходимости сравнивает объекты через equals(). А мы переопределили equals(), но не переопределили hashCode().

Поэтому два объекта:

new User("[email protected]")
new User("[email protected]")

считаются равными через equals(), но могут иметь разные хэш-коды. В результате HashSet ищет второй объект не там, где находится первый.

Как исправить?

Если переопределяем equals(), необходимо согласованно переопределить и hashCode():

@Override
public int hashCode() {
return email.hashCode();
}

Теперь объекты с одинаковым email будут иметь одинаковый хэш-код, и HashSet сможет корректно их находить.



Такая ошибка особенно коварна:
• Компилятор не ругается;
• Приложение не падает;
• equals() работает именно так, как мы ожидаем;
• Проблема проявляется только при использовании хэш-коллекций.

И внезапно оказывается, что:

set.contains(user)

возвращает false, хотя объект с такими же данными в Set уже есть.



Если объект должен использоваться в HashSet, HashMap или других структурах на основе хэширования, всегда проверяйте контракт между equals() и hashCode():

Если два объекта равны через equals(), их hashCode() должен быть одинаковым.

Но обратное утверждение неверно: если у двух объектов одинаковый hashCode(), это ещё не означает, что они равны через equals().
Одинаковый хэш может быть у разных объектов — это называется коллизией.

А встречались с ситуацией, когда объект «есть» в коллекции, но contains() почему-то говорит обратное?

#Y_LAB_University #Y_LAB_Actual

Новый пост Y_LAB Actual | Код под микроскопом

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

Сегодня под микроскопом — секреты в Docker
Представим, что разработчику нужно передать API-ключ приложению:

FROM python:3.12

ENV API_KEY="super-secret-key"

COPY . .

CMD ["python", "app.py"]

приложение получает ключ;
контейнер запускается;
секрет не нужно хранить отдельно от проекта.

Но в таком подходе есть серьёзная проблема.
Секрет оказывается внутри Docker-образа.

А образ — это не просто один файл с приложением. Docker хранит историю его слоёв, и информация, которая попала в один из них, может остаться доступной даже после того, как строку удалили из Dockerfile.
То есть разработчик может сделать:

ENV API_KEY="super-secret-key"

а потом заменить это на:

ENV API_KEY=""

и пересобрать образ.

Но это ещё не означает, что старый ключ исчез из истории.


Как сделать безопаснее

Секреты лучше передавать во время запуска контейнера или использовать специальные механизмы управления секретами.
Например:

docker run \
-e API_KEY="$API_KEY" \
my-app

Теперь ключ не нужно записывать непосредственно в Dockerfile.

А в более крупных системах для хранения секретов используют специальные инструменты: secret management в Kubernetes, Docker Secrets, Vault и облачные менеджеры секретов.



Docker-образ может попасть:
• в container registry;
• на CI/CD-сервер;
• на сервер разработчика;
• к другому члену команды.

Если внутри образа оказался настоящий API-ключ, пароль или токен, это уже не просто технический долг. Это потенциальный инцидент безопасности.

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

А доводилось находить API-ключи или пароли прямо в Docker-образах, Git-репозиториях или CI/CD?

#Y_LAB_University #Y_LAB_Actual

Новый пост Y_LAB Actual | Код под микроскопом

Продолжаем рубрику, в которой разбираем реальные инженерные ситуации и ищем причины проблем, которые не всегда очевидны на первый взгляд.
Сегодня под микроскопом — React и повторные запросы

function UserProfile({ userId }) {
const [user, setUser] = useState(null);

const options = {
headers: {
Authorization: "Bearer token"
}
};

useEffect(() => {
fetch(`/api/users/${userId}`, options)
.then(response => response.json())
.then(setUser);
}, [userId, options]);

return <div>{user?.name}</div>;
}

Почему при обычном рендере компонента API может начать получать множество одинаковых запросов?

useEffect зависит от userId;
запрос выполняется при изменении пользователя;
после получения данных вызывается setUser.

Но есть одна проблема:

const options = {
headers: {
Authorization: "Bearer token"
}
};

Этот объект создаётся заново при каждом рендере компонента.

А useEffect следит за ним:

[userId, options]

React сравнивает зависимости по ссылке.
Поэтому для него:

options → старый объект
options → новый объект

— это разные значения, даже если содержимое объектов полностью одинаковое.

Что происходит дальше?

Компонент рендерится -> Создаётся новый options -> useEffect отправляет запрос -> При получении ответа вызывается setUser -> Компонент снова рендерится -> Создаётся новый options -> React считает зависимость изменившейся -> useEffect снова отправляет запрос

И так запросы могут начать повторяться снова и снова.

Как исправить?

Если объект действительно не меняется, его можно вынести за пределы компонента:

const options = {
headers: {
Authorization: "Bearer token"
}
};

function UserProfile({ userId }) {
const [user, setUser] = useState(null);

useEffect(() => {
fetch(`/api/users/${userId}`, options)
.then(response => response.json())
.then(setUser);
}, [userId]);

return <div>{user?.name}</div>;
}

Но иногда проблема решается не внутри самого компонента. Можно вынести работу с API в отдельный слой. Например, компонент отвечает только за отображение данных, а запросы находятся в отдельном сервисе:

Component
↓
API layer
↓
Backend

Ещё один вариант — использовать библиотеку для работы с серверными данными. Например, TanStack Query или RTK Query. Они позволяют вынести запросы и управление их состоянием за пределы компонентов, а также предоставляют кэширование, дедупликацию запросов и другие механизмы для работы с серверными данными. В результате компоненту не обязательно самостоятельно решать, когда отправить запрос, где хранить результат и нужно ли повторно загружать те же данные.



Один лишний запрос кажется мелочью. Но если такой компонент находится на странице, которая активно обновляется, или подобных компонентов десятки, количество запросов может быстро вырасти.
В итоге можно получить:

Лишнюю нагрузку на API;
Замедление интерфейса;
Превышение rate limit;
Неожиданные 429 Too Many Requests;
Лишние расходы на инфраструктуру.

И проблему не всегда получится обнаружить просто открыв Network DevTools. Если запрос выполняется на сервере (например, при SSR или в Server Components), его вообще может не быть среди сетевых запросов браузера. Поэтому при подозрении на лишние обращения к API стоит смотреть не только на frontend, но и на логи, метрики и трассировку запросов.

А замечали когда-нибудь, что один компонент способен породить десятки одинаковых запросов?

#Y_LAB_University #Y_LAB_Actual

Новый пост Y_LAB Actual | Код под микроскопом

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

Сегодня под микроскопом — кэширование браузера

// HTML

<link rel="stylesheet" href="/css/style.css">
<script src="/js/app.js"></script>

Вопрос:

Вы исправили баг, выкатили новую версию приложения, деплой прошёл успешно…
Но часть пользователей продолжает видеть старый интерфейс.

Почему

Сначала кажется, все верно:

Новый код загружен на сервер;
Сборка завершилась без ошибок;
Приложение доступно.

Но проблема может быть совсем не в сервере.

Браузер уже сохранил файлы:

// text

/css/style.css
/js/app.js

и при следующем открытии страницы может использовать их из собственного кэша.
В результате пользователь продолжает работать со старой версией приложения, хотя на сервере уже лежит новая.

Как обычно решают эту проблему?

Во многих проектах к имени файла автоматически добавляют хэш:

// HTML

<link rel="stylesheet" href="/css/style.a4f91c.css">
<script src="/js/app.82de13.js"></script>

После новой сборки хэш меняется:

// text

app.82de13.js
↓
app.f93b11.js

Для браузера это уже новый файл, поэтому он скачивает его заново, а не использует старую версию из кэша.
Именно поэтому современные инструменты сборки (Webpack, Vite, Rollup и другие) по умолчанию добавляют хэш в имена файлов.



Если после релиза пользователи говорят: «У меня всё осталось по-старому», не спешите искать ошибку в коде.
Сначала проверьте, не связана ли проблема с кэшированием и версионированием статических файлов.

А вам приходилось сталкиваться с ситуацией, когда причина бага оказалась не в коде, а в старой версии файлов, оставшейся в кэше?

#Y_LAB_University #Y_LAB_Actual