❌ Зависшие ссылки в замыканиях

Когда компонент или объект был удалён, но замыкание всё равно сохраняет ссылку на данные, они не могут быть очищены. Это классическая ошибка, особенно при больших данных.

Проблема (в примерах): bigData остаётся в памяти, пока существует ссылка на колбэк.

❌ Глобальные переменные

Ошибки с глобальными переменными часто возникают, когда забывают использовать const или let.

Проблема (в примерах): Любой объект в глобальной области будет жить вечно.

❌ Слушатели событий и DOM-узлы

Если слушатели событий или DOM-узлы не удаляются после того, как элементы были удалены, это может привести к утечкам. Особенно часто это случается с модальными окнами или кастомными компонентами.

Проблема (в примерах): После удаления элемента слушатель остаётся, удерживая объект в памяти.

❌ Неправильное использование таймеров

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

Проблема: Таймер продолжает работать, сохраняя контекст.

❌ Неправильное использование таймеров

Таймеры, такие как setInterval, могут стать серьезным источником утечек памяти, если не очищаются при уходе со страницы или продолжают ссылаться на контекст.

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

❌ Кэши без лимитов

Попытки сделать «умное кэширование» без ограничений на размер могут привести к утечкам.

Проблема (в примерах): Без лимитов на кэш память будет заполняться бесконечно.

❌ Проблемы с Web Workers

Ошибки в работе с Web Workers, такие как передача данных без Transferables или не закрытые воркеры, могут стать причиной утечек.

❌ Сторонние библиотеки

Некоторые библиотеки, особенно для UI, могут создавать скрытые DOM-структуры и не очищать их по завершении работы, что также ведет к утечкам.

❌ React: stale effects

В React утечки могут происходить из-за старых ссылок в эффектах, которые не пересоздаются.

Проблема (в примерах): Эффект не пересоздается, старые ссылки остаются.

// Зависшие ссылки в замыканиях
function createTracker() {
const bigData = new Array(1_000_000).fill('x');
return () => console.log(bigData.length);
}

// Глобальные переменные
foo = {}; // теперь это window.foo

// Слушатели событий и DOM-узлы
element.addEventListener('scroll', handler);
// element.removeEventListener(...) забыли

// Кэши без лимитов
const cache = {};
cache[key] = heavyObject;

// React: stale effects
useEffect(() => {
subscribe();
return () => unsubscribe();
}, []); // но зависимость должна быть!

Слабый инженер пишет код, который работает.
Сильный - код, который можно изменить через год.

Простой код:
🔘 легче читать
🔘 легче тестировать
🔘 легче рефакторить

Самая дорогая операция в проекте - не вычисление.
А понимание чужого кода.

Если решение:
🔘 требует 10 минут объяснений
🔘 построено на «красивом» хаке
🔘 использует экзотические паттерны

Новички часто хотят показать, что знают:
🔘 сложные абстракции
🔘 хитрые дженерики
🔘 продвинутые паттерны

Сильные инженеры знают другое правило:
если можно проще - нужно проще.

Абстракция - это не подарок. Это долг.

Каждый дополнительный слой - это:
🔘 когнитивная нагрузка
🔘 новая точка отказа
🔘 усложнённый дебаг

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

Простой код - это:
🔘 явные зависимости
🔘 понятные названия
🔘 минимум магии
🔘 предсказуемое поведение

Чтобы писать так, нужен опыт.
Потому что простота - результат множества осознанных решений.