Приведи пример, когда приходилось перенимать задачи других людей

Пример: Перенимание Критического Бага в Production

Хорошо, расскажу конкретный случай, когда мне пришлось перенять задачу, которая была на очень критическом этапе. Это произошло в проекте платежной системы для e-commerce компании.

Ситуация

В пятницу в 17:00 Иван, senior backend разработчик, начал рефакторинг API для обработки платежей. Это было плановой задачей на спринт. Однако в 20:00 сотрудник из поддержки обнаружил критический баг: некоторые платежи не попадали в базу данных, хотя были обработаны платёжным гейтвеем.

Проблема была критической:

• Расхождение в балансах между нашей БД и платёжным гейтвеем
• Неясно, сколько платежей потеряно
• Иван был полностью занят своим рефакторингом
• Нужно было срочно разобраться

Пм попросил меня взять эту задачу.

Мои Действия

Шаг 1: Быстрое Ознакомление (30 минут)

Я не начал сразу писать код. Вместо этого:

1. Прочитал issue в Jira с описанием проблемы
2. Спросил у Ивана: "Что ты делаешь в рефакторинге? Это может быть связано с этим багом?"
3. Иван сказал, что рефакторинг касается другого части кода, не платежей
4. Посмотрел recent commits в ветке payments — за последние 2 дня ничего не менялось
5. Попросил доступ к production логам

Пример из conversation с Иваном:

Я: "Какие были последние изменения в платежах?"
Иван: "Ничего за неделю. Рефакторю только API routes."
Я: "Это может быть на production стороне? Может платежный гейтвей изменился?"
Иван: "Хорошая идея, проверь их API docs и changelog."

Шаг 2: Анализ Логов (45 минут)

В production логах я нашёл паттерн:

2024-03-15 18:23:45 POST /api/v1/payments - 200 OK
2024-03-15 18:23:46 INSERT INTO payments - SUCCESS
...
2024-03-15 19:45:12 POST /api/v1/payments - 200 OK
❌ INSERT INTO payments - FAILED (connection timeout)
2024-03-15 19:45:13 Response: 200 OK (уже отправлен клиенту!)

Нашёл проблему:

• API возвращает 200 OK клиенту
• Но INSERT в БД падает с timeout
• Результат: платёжный гейтвей думает, что платёж обработан (200 OK), а в нашей БД его нет

Шаг 3: Понимание Почему Это Произошло

Посмотрел код:

// ❌ Проблемный код
export async function processPayment(req: Request, res: Response) {
  const paymentData = req.body;
  
  // Отправляем 200 OK СРАЗУ
  res.json({ status: 'accepted' });
  
  // А ПОТОМ пытаемся сохранить в БД (асинхронно)
  database.savePayment(paymentData).catch(error => {
    logger.error('Failed to save payment:', error);
    // Но клиент уже получил 200 OK!
  });
}

Контроллер отправляет успешный ответ ПЕРЕД сохранением в БД. Если сохранение падает — клиент не узнает об этом.

Шаг 4: Обсуждение с Командой

Звонок с Иваном, PM и техническим лидером:

• Объяснил проблему
• Предложил несколько вариантов решения
• Обсудили срочность (это critical issue)

Варианты Решения

Вариант 1: Синхронное Сохранение (быстро)

export async function processPayment(req: Request, res: Response) {
  const paymentData = req.body;
  
  try {
    // Сначала сохраняем в БД
    const payment = await database.savePayment(paymentData);
    // Только потом отправляем 200 OK
    res.json({ status: 'success', payment });
  } catch (error) {
    res.status(500).json({ status: 'failed', error: error.message });
  }
}

Плюсы:

• Простое решение
• Работает
• Быстро реализовать

Минусы:

• Если БД медленна, клиент ждёт долго (timeout у платёжного гейтвея)
• Может привести к timeout'ам со стороны платежей

Вариант 2: Очередь (правильно, но долго)

export async function processPayment(req: Request, res: Response) {
  const paymentData = req.body;
  
  try {
    // Сохраняем в очередь (быстро)
    const jobId = await queue.enqueue('processPayment', paymentData);
    res.json({ status: 'pending', jobId });
    
    // В отдельном воркере обрабатываем асинхронно
    // Если падает — можем retry
  } catch (error) {
    res.status(500).json({ status: 'failed' });
  }
}

// Worker
queue.on('processPayment', async (paymentData) => {
  try {
    await database.savePayment(paymentData);
  } catch (error) {
    queue.retry(); // Повторим позже
  }
});

Плюсы:

• Масштабируемо
• Надёжно (retry mechanism)
• Асинхронная обработка

Минусы:

• Сложнее реализовать
• Нужна очередь (Redis, RabbitMQ)
• Требует больше времени на разработку

Мой Выбор и Аргументы

Я предложил Вариант 1 как временное решение и Вариант 2 как долгосрочное:

Я: "В пятницу в 20:00 нам нужна стабильность, не совершенство. 
Предлагаю:

1. Сейчас: Синхронное сохранение (30 минут на разработку + тесты)
2. На следующей неделе: Внедрить очередь (2-3 дня на разработку)

Аргументы:
- Синхронное решение восстановит доверие платёжного гейтвея
- Если БД медленна, мы это увидим в логах и сможем оптимизировать
- Затраты на производительность минимальны (платежи это не 10K qps)

Что думаете?"

Вся команда согласилась.

Реализация

Шаг 1: Исправить Код (20 минут)

export async function processPayment(req: Request, res: Response) {
  const paymentData = req.body;
  const startTime = Date.now();
  
  try {
    // Валидируем данные
    validatePayment(paymentData);
    
    // Сохраняем в БД (с timeout)
    const payment = await Promise.race([
      database.savePayment(paymentData),
      timeout(5000) // 5 секунд timeout
    ]);
    
    logger.info(`Payment ${payment.id} saved in ${Date.now() - startTime}ms`);
    res.json({ status: 'success', payment });
  } catch (error) {
    logger.error(`Payment failed: ${error.message}`);
    res.status(500).json({ status: 'failed', error: error.message });
  }
}

Шаг 2: Написать Тесты (30 минут)

describe('Payment Processing', () => {
  it('should save payment before returning success', async () => {
    const paymentData = { amount: 100, currency: 'USD' };
    const response = await request(app).post('/api/v1/payments')
      .send(paymentData);
    
    expect(response.status).toBe(200);
    const savedPayment = await database.findPayment(paymentData.id);
    expect(savedPayment).toBeDefined();
  });
  
  it('should return error if database save fails', async () => {
    mockDatabase.savePayment.mockRejectedValue(new Error('DB error'));
    const response = await request(app).post('/api/v1/payments')
      .send({ amount: 100 });
    
    expect(response.status).toBe(500);
  });
});

Шаг 3: Деплой в Production (10 минут)

• Code review у техлида
• Deploy в staging
• Проверка логов
• Deploy в production

Результаты

После исправления:

• Все платежи стали сохраняться в БД
• Логи показали, что всё работает нормально
• На следующей неделе внедрили очередь для асинхронной обработки

Время на решение: примерно 2 часа от начала до деплоя в production.

Что Я Сделал Правильно

1. Не паниковал — спокойно разобрался в проблеме
2. Спросил у предыдущего разработчика — узнал контекст
3. Проанализировал логи — нашёл корень проблемы
4. Предложил варианты — обсудил с командой
5. Выбрал правильный баланс — срочное vs правильное
6. Написал тесты — убедился, что это не повторится
7. Документировал — постморт для команды

Заключение

Этот пример показывает:

• Коммуникация важнее скорости (спросил у Ивана вместо гадания)
• Данные решают всё (логи показали точную проблему)
• Баланс критичен (быстрое решение сейчас + правильное позже)
• Разработчик должен быть гибким (взять срочную задачу и решить её хорошо)

Вот такой пример, когда я перенял чужую задачу в критический момент.