Расскажи про факапы на работе

Факапы на работе

Факапы — это нормальная часть жизни разработчика. Важно не их избегать, а учиться на них. Расскажу про реальные ситуации и выводы из них.

1. Deploy в production во время встречи с инвесторами

Что произошло: Деплоил изменения в production, а параллельно шла демонстрация продукта инвесторам. Забыл добавить env переменную для новой функции. Сайт упал на 5 минут.

Причина:

• Не проверил dev environment перед деплоем
• Запустил deploy в неправильное время
• Не было rollback плана

Чему научился:

• Всегда проверять все env переменные перед деплоем
• Согласовывать время деплоев с командой
• Иметь готовый способ быстрого отката
• Использовать staging environment как последнюю проверку

2. Забыл про race condition в асинхронном коде

Что произошло: Написал запрос к API, который загружает список пользователей. Если кликнуть несколько раз быстро на кнопку, старые запросы перезаписывают новые. Результат — пользователь видит устаревшие данные.

// Плохо — race condition
const fetchUsers = async () => {
  const data = await api.getUsers();
  setUsers(data); // может быть переписано старым запросом
};

// Хорошо — отмена старых запросов
const fetchUsers = async () => {
  const controller = new AbortController();
  try {
    const data = await api.getUsers({
      signal: controller.signal
    });
    setUsers(data);
  } catch (e) {
    if (e.name !== "AbortError") throw e;
  }
  return () => controller.abort();
};

Вывод:

• Всегда обрабатывать race conditions в асинхронном коде
• Использовать AbortController для отмены старых запросов
• Писать тесты на race conditions

3. Сломал мобильную версию новым CSS

Что произошло: Добавил новый CSS для десктопа, забыл про мобильные брейкпоинты. На телефоне кнопка стала невидна и невозможна для клика.

/* Плохо — не учёл мобильность */
.button {
  width: 500px; /* слишком широко для мобилки */
}

/* Хорошо — mobile-first */
.button {
  width: 100%;
}

@media (min-width: 768px) {
  .button {
    width: auto;
  }
}

Вывод:

• Тестировать на реальных устройствах (не только DevTools)
• Использовать mobile-first подход
• Добавить E2E тесты на адаптивность

4. Недочёт в типизации привёл к багу

Что произошло: Передал объект как any в функцию, и затем колледжа получил undefined вместо ожидаемого значения. Баг обнаружили в production.

// Плохо — any
const processData = (data: any) => {
  return data.user.name; // может упасть
};

// Хорошо — строгая типизация
interface UserData {
  user: {
    name: string;
  };
}

const processData = (data: UserData) => {
  return data.user.name; // гарантировано строка
};

Вывод:

• Не использовать any в TypeScript
• Всегда типизировать API ответы
• Использовать strict mode в tsconfig.json

5. Забыл про production данные

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

Вывод:

• Всегда проверять на real data перед деплоем
• Использовать логирование и мониторинг
• Иметь staging окружение, идентичное production
• Писать unit тесты с реалистичными данными

6. Неправильно обработал ошибку при загрузке данных

Что произошло: Когда API возвращает ошибку, я просто логировал её в консоль. Пользователь не видел никакой ошибки и думал, что приложение зависло.

// Плохо — пользователь не видит ошибку
const fetchData = async () => {
  try {
    const data = await api.getData();
    setData(data);
  } catch (e) {
    console.error(e); // только в консоли!
  }
};

// Хорошо — показываем пользователю
const fetchData = async () => {
  setLoading(true);
  try {
    const data = await api.getData();
    setData(data);
  } catch (e) {
    setError("Не удалось загрузить данные");
  } finally {
    setLoading(false);
  }
};

Вывод:

• Всегда показывать пользователю ошибку
• Имплементировать Loading, Error, Success состояния
• Логировать ошибки на сервер (Sentry, LogRocket)

Как я избегаю факапов сейчас

Процесс:

1. Пишу тесты перед кодом (TDD)
2. Локально проверяю все сценарии
3. Запускаю staging как финальную проверку
4. Ревьюю свой код перед PR
5. Просрочиваю деплой за час до встреч
6. Настроил мониторинг и алёрты

Инструменты:

• E2E тесты (Playwright, Cypress)
• Unit тесты (Jest, Vitest)
• Линтинг и type checking (ESLint, TypeScript strict)
• Error tracking (Sentry)
• Performance monitoring (Lighthouse, Core Web Vitals)

Итог

Факапы случаются у всех. Важно:

• Принять их как часть процесса
• Разобраться почему это произошло
• Написать тест чтобы это не повторилось
• Поделиться опытом с командой
• Улучшить процесс чтобы минимизировать вероятность

Именно на факапах люди становятся опытнее.