Что будешь делать если нужно исправить ошибку коллеги?

Как исправить ошибку коллеги

Это один из самых важных навыков в командной разработке. За 10+ лет выработал систему, которая сохраняет отношения и качество кода.

Принципы взаимодействия

1. Предположение позитива

Всегда предполагаю, что коллега:

• Сделал лучшее, что мог в момент написания кода
• Не имел полной информации
• Спешил или был отвлечён

Никогда не думаю: "Как он такое мог написать?", а думаю: "Какой контекст я упускаю?"

2. Конфиденциальность

# Плохо - обсуждать ошибку публично
# На standup: "Вася написал код который падает"

# Хорошо - говорить наедине
# Slack DM: "Привет, заметил момент в твоём PR..."

3. Техническое, не личное

Основываюсь на:

• Коде (что там написано)
• Требованиях (что было нужно)
• Лучших практиках (как обычно делают)

Не критикую:

• Способности коллеги
• Его прошлые ошибки
• Его характер

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

Этап 1: Диагностика

# Я вижу этот код
def calculate_price(items):
    total = 0
    for item in items:
        total = total + item["price"]  # ошибка: нет проверки None
    return total

# Действие: не сразу бегу к коллеге
# Вопросы к себе:
# 1. Это действительно ошибка?
# 2. Когда она проявляется?
# 3. Критичная ли она?
# 4. Есть ли тесты?
# 5. Может ли это вызвать проблемы в production?

Этап 2: Выбор канала коммуникации

Выбираю по severity:

error_type = {
    "critical": {
        "description": "Приложение падает, data loss, security",
        "action": "Immediate call/chat",
        "tone": "Спокойный, фактический"
    },
    "high": {
        "description": "Bug в логике, wrong data",
        "action": "Slack message/PR comment",
        "tone": "Вежливый, предложить помощь"
    },
    "medium": {
        "description": "Code style, performance, missing test",
        "action": "PR review comment",
        "tone": "Конструктивный, как учить"
    },
    "low": {
        "description": "Minor style issue",
        "action": "Следующий refactoring",
        "tone": "Suggestion, not requirement"
    }
}

Этап 3: Формулировка feedback

Успешное сообщение имеет структуру:

# Плохо
# "Это же очевидная ошибка! Как можно забыть про None check?"

# Хорошо
# "Привет! Заметил в твоём коде:
# 
# В функции calculate_price если price будет None,
# получим TypeError. Можем добавить проверку?
# 
# Вариант 1: price or 0
# Вариант 2: price if price is not None else 0
# 
# Или может это уже обработано на уровне валидации?
# Давай обсудим."

Конкретная тактика

Для PR reviews

Структура комментария:

1. Что я вижу
2. Почему это проблема
3. Предложение
4. Открытость к диалогу

Прямой диалог (critical ошибка)

# Сценарий: Ошибка в production

# Верный подход:
# 1. Быстро alert: "У нас проблема в production"
# 2. В зуме обсуждаем техническое решение
# 3. После fix: retrospective без обвинений
# 4. Документируем learnings

# Неверный подход:
# - Искать виноватого
# - Критиковать при других
# - Говорить: "Я же говорил!"

Трудные ситуации

Если коллега защищается

# Коллега: "Это работает же!"
# Мой ответ: "Да, работает. Но есть edge case..."
# Не настаиваю, объясняю

# Коллега: "Это не моя ошибка, это требования"
# Мой ответ: "Поехали вместе к PM обсудим"
# Помогаю, не обвиняю

Если ошибка систематическая

# Если коллега делает одну ошибку много раз:
# - Не мозолю ему на эту ошибку в каждом PR
# - Предлагаю помощь: "Хочешь, я покажу как это делается?"
# - Может быть, это пробел в знаниях или процессе
# - Привлекаю tech lead для training/mentoring

def get_user_by_id(user_id):
    user = User.objects.get(id=user_id)  # Нет try-except
    return user

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

Всегда:

• Поблагодари коллегу за внимание к feedback
• Признай если я тоже ошибался
• Помни что ошибки — это нормально и помогают расти

Может быть:

• Предложить pair programming в будущем
• Провести knowledge sharing сессию для команды
• Обновить code style guide если нужно

Главный принцип

Code review — это не контроль, а сотрудничество. Мы все работаем на одну цель: качественный, поддерживаемый код. Ошибки неизбежны, и это OK. Важно как мы их обсуждаем.