Ошибка 5 — игнорировать ошибки и тесты

Почему «работает у меня» — это иллюзия

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

Минимальный набор проверок

Проверка типов TypeScript

npm run typecheck
# или прямо: npx tsc --noEmit

Эта команда находит ошибки типизации ещё до сборки, поэтому запускать её стоит после каждой итерации с агентом.

Линт

npm run lint

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

Сборка

npm run build

Это финальная проверка, которая имитирует сборку для боевого сервера. Если она падает, значит на сервере проект тоже упадёт.

Базовые тесты

Первую рабочую версию можно выпускать и без тестов, но по мере роста проекта они становятся обязательными. Минимум — это модульные тесты для критичных функций (расчёт цены, проверка авторизации, обработка webhook) и один сквозной тест на сценарий «зарегистрироваться, купить, получить продукт». Такой единственный сценарий перекрывает большинство ошибок во всей воронке.

Настройка автозапуска проверок

Pre-commit hook (Husky)

npm install --save-dev husky lint-staged
npx husky init

# В .husky/pre-commit:
npm run typecheck && npm run lint

Каждый коммит — автоматически проверяет. Сломанный код не попадёт в git.

CI-проверки (GitHub Actions)

Файл .github/workflows/ci.yml:

name: CI
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 20 }
      - run: npm ci
      - run: npm run typecheck
      - run: npm run lint
      - run: npm run build

Теперь проверяется и каждый пуш в репозиторий: если CI красный, выкат основной ветки не произойдёт.

Что делать при ошибке

Увидев ошибку, всегда есть два пути. Можно её «скрыть» — проигнорировать предупреждение, отключить правило линта, добавить // @ts-ignore. А можно «разобраться» — понять, что не так, и исправить корректно. Соблазн скрыть очень велик, ведь это быстрее на пару секунд. Но такие подавленные предупреждения накапливаются, и каждое из них — это бомба замедленного действия. Отсюда правило: каждый // @ts-ignore или eslint-disable обязан сопровождаться комментарием, почему это допустимо. Без такого комментария глушить ошибку нельзя.

Особое внимание — обработка ошибок

У ИИ-агентов очень типичный антипаттерн в обработке ошибок:

try {
  ...
} catch (e) {
  console.log(e);
}

Здесь ошибка проглатывается: пользователь не понимает, что именно не получилось, а в логах не остаётся ничего полезного. В боевом режиме это критично. Правильная обработка устроена иначе. В API нужно возвращать понятный HTTP-статус (400, 402, 500) с сообщением, на интерфейсе — показывать пользователю всплывающее уведомление с человеческим текстом, в логи писать структурированный объект с контекстом, а не только текст ошибки, и обязательно подключить систему отслеживания ошибок для боевого режима.

Отслеживание ошибок

Без отслеживания ошибок в боевом режиме вы не узнаете о большей части проблем: пользователи просто уходят и ничего не пишут. Из доступных вариантов Sentry — стандарт индустрии с бесплатным тарифом и быстрым подключением в Next.js. PostHog даёт отслеживание ошибок вместе с продуктовой аналитикой и тоже имеет щедрый бесплатный тариф. А связка OpenTelemetry с Grafana подойдёт тем, кто разворачивает всё на собственной инфраструктуре.

Что в следующем уроке

Тесты, проверки и мониторинг — это страховка. Но не менее важно следить за расходом денег на ИИ-запросы. На следующем уроке разберём, как не сжигать лимиты Claude Pro и OpenRouter впустую.