Расскажи про самые серьезные ошибки

Самые серьезные ошибки во Frontend-разработке

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

1. Пренебрежение производительностью и Core Web Vitals

Это самая распространенная и дорогостоящая ошибка. Медленный сайт = потеря пользователей и денег. Частые проявления:

• Гигантские несжатые ресурсы: Загрузка изображений в 3x-4x большем размере, чем требуется для экрана, отсутствие форматов нового поколения (WebP/AVIF), отсутствие сжатия для JS/CSS.
• Неоптимальная загрузка JavaScript: Отправка всего бандла на первую загрузку, отсутствие ленивой загрузки (React.lazy, динамические import()) для модулей, не критичных для первого рендера.
• Неуправляемые ререндеры в React/Vue: Классическая ошибка — создание новых объектов/функций в теле компонента на каждом рендере, что ломает мемоизацию (React.memo, useMemo, useCallback) и заставляет дочерние компоненты обновляться без необходимости.

// ❌ ПЛОХО: Новая функция и объект создаются при каждом рендере -> дочерний компонент всегда ререндерится.
function ParentComponent() {
  const handleClick = () => console.log('Click');
  const data = { id: 1 };

  return <ChildComponent onClick={handleClick} data={data} />;
}

// ✅ ХОРОШО: Мемоизация стабилизирует ссылки.
function ParentComponent() {
  const handleClick = useCallback(() => console.log('Click'), []);
  const data = useMemo(() => ({ id: 1 }), []);

  return <ChildComponent onClick={handleClick} data={data} />;
}

• Игнорирование метрик LCP, FID, CLS. Например, CLS (Cumulative Layout Shift) — это визуальная нестабильность. Пользователь пытается кликнуть на кнопку, и в последний момент под ней грузится рекламный баннер, смещая интерфейс. Клик приходится на другое место. Это катастрофа для UX.

2. Отсутствие стратегии управления состоянием (State Management)

Начинают с useState и useContext в React, но по мере роста приложения это превращается в хаос пропсов (prop drilling) и непредсказуемых обновлений.

• Глобальный Context для часто изменяющихся данных: Context — не стейт-менеджер. Любое изменение значения в провайдере вызывает ререндер всех потребителей, даже если они используют лишь часть данных.
• Дублирование состояния: Одна и та же данные в разных компонентах синхронизируются вручную, что неизбежно ведет к расхождениям.
• Решение: Для сложного состояния нужна специализированная библиотека (Zustand, Redux Toolkit, MobX), которая обеспечивает гранулярные обновления, middleware (логирование, DevTools), и четкие паттерны.

3. Бездумное использование сторонних пакетов (Dependency Bloat)

Установка npm-пакета на каждую мелкую задачу — путь к катастрофе.

• Уязвимости безопасности: Чем больше зависимостей, тем шире поверхность для атак.
• Раздутие бандла: Один import из lodash может потянуть за собой всю библиотеку, если не настроен tree-shaking или не используется импорт конкретных функций (import debounce from 'lodash/debounce').
• Блокировка обновлений: Глубокие цепочки зависимостей могут заблокировать обновление ядра фреймворка.
• Правило: Всегда оценивай стоимость зависимости. Нужна ли целая UI-библиотека для одной кнопки? Можно ли реализовать функцию debounce в 10 строчек кода самостоятельно?

4. Неадекватная обработка ошибок и состояний загрузки

Представление, что "всегда будет работать", — наивно.

• "Белый экран смерти" из-за непойманной ошибки в компоненте.
• Отсутствие индикаторов загрузки при сетевых запросах, что заставляет пользователя думать, что интерфейс "сломан".
• Игнорирование ошибочных состояний сети (офлайн, медленное соединение).
• Решение: Обязательное использование Error Boundaries в React, скелетоны/спиннеры для загрузки, стратегии retry для запросов, понятные сообщения об ошибках.

// React Error Boundary (упрощенно)
class ErrorBoundary extends React.Component {
  state = { hasError: false };
  static getDerivedStateFromError(error) { return { hasError: true }; }
  componentDidCatch(error, info) { /* Отправка в лог (Sentry) */ }
  render() {
    if (this.state.hasError) {
      return <FallbackUI />; // Показываем запасной интерфейс
    }
    return this.props.children;
  }
}

5. Недостаточное внимание accessibility (a11y)

Это не просто "для галочки", а юридическое требование и этическая норма. Ошибки:

• Несемантическая верстка: Бесконечные <div> и <span> вместо <button>, <nav>, <article>. Скринридеры не поймут структуру страницы.
• Отсутствие или некорректные ARIA-атрибуты: aria-label, aria-expanded, aria-live.
• Невозможность управления с клавиатуры: Все интерактивные элементы должны иметь фокус и обрабатывать Enter/Space.
• Неконтрастные цвета: Текст должен быть читаемым для людей с нарушением зрения.

6. Игнорирование безопасности (Security)

Frontend — это не безопасно "по определению", но ошибки здесь открывают двери для атак.

• XSS (Межсайтовый скриптинг): Самая опасная. Прямая вставка несанитизированных пользовательских данных в innerHTML или в атрибуты через шаблонные строки.

  // ❌ КРИТИЧЕСКАЯ УЯЗВИМОСТЬ
  element.innerHTML = userComment; // Если в comment: `<script>stealCookies()</script>`
  

    **Всегда** санитизируйте или экранируйте пользовательский ввод, используйте `textContent` вместо `innerHTML`, или библиотеки типа `DOMPurify`.

• Утечка чувствительных данных в коде: API-ключи, хардкод credentials в JS-файлах, которые видны всем в исходном коде страницы.

7. "Магический" код и отсутствие документации

Стремление написать "умную" одну строчку часто оборачивается кошмаром для команды и для тебя самого через полгода.

• Слишком сложная абстракция: Паттерны "для красоты", которые только увеличивают когнитивную нагрузку.
• Отсутствие комментариев к неочевидной бизнес-логике.
• "Подводные камни" в коде, о которых знает только автор. При его уходе команда обречена на дебаггинг.

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