Что делать если ревьюер неправ и настаивает на своем мнении

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

Основной принцип: избегать конфронтации, стремиться к коллаборации

Первое и главное — отбросить эмоции и воспринимать ситуацию не как «он неправ, а я прав», а как разногласие в техническом подходе, которое нужно разрешить для улучшения качества кода и продукта. Цель — не победить, а найти наилучшее решение для проекта.

Пошаговый план действий

1. Глубокий анализ и рефрейминг

Прежде чем отвечать, я делаю паузу и задаю себе вопросы:

• Действительно ли я всецело прав? Возможно, я упускаю какой-то контекст (будущие требования, смежные системы, прошлые инциденты), которым владеет ревьюер.
• Почему ревьюер так считает? В его комментарии может быть скрыта ценная озабоченность (concern) о читаемости, производительности, согласованности архитектуры или будущей поддержке.
• Является ли вопрос принципиальным? Это касается безопасности, производительности, архитектурного стиля или же это вкусовщина (именование переменных, расстановка скобок)? Для второго часто проще принять стиль команды.

2. Детальное обоснование своей позиции (в комментарии)

Я отвечаю не односложно («Нет, это неверно»), а развернуто, используя конкретные аргументы:

• Ссылаюсь на принципы: SOLID, KISS, YAGNI, паттерны проектирования.
• Привожу данные: бенчмарки, логи, метрики.
• Указываю на документацию: официальная документация Android/Java/Kotlin, гайдлайны (Android Developer Guides, Google's API Guides), кодстайл команды.
• Демонстрирую последствия: «Если сделать, как ты предлагаешь, это может привести к X в будущем, потому что...».
• Предлагаю альтернативу, если его решение имеет минусы: «Я понимаю твою озабоченность по поводу Y. Давай рассмотрим вариант Z, который решит проблему Y, но избежит недостатков моего изначального и твоего подходов».

// Пример комментария в ревью
// Ревьюер: "Зачем тут корутина? Сделай просто вызов blockingCall()."
// Мой ответ:
/**
Спасибо за комментарий! Я использовал корутину здесь сознательно, по двум причинам:
1. **`blockingCall()` выполняется 2-3 секунды** (согласно нашим метрикам). Вызов на главном потоке приведет к анр ответу (>16мс) и подтормаживанию UI.
2. **Архитектурная согласованность:** Весь этот экран построен на корутинах в `ViewModel`. Добавление blocking-вызова нарушит эту модель и усложнит обработку ошибок и отмены.
Предлагаю оставить корутину. Если есть опасения по поводу сложности кода, я могу вынести эту логику в отдельный `UseCase` для лучшей читаемости.
*/
private fun loadData() {
    viewModelScope.launch {
        _state.value = State.Loading
        try {
            val result = repository.blockingCall() // Но он вызывается в IO-диспетчере
            _state.value = State.Success(result)
        } catch (e: Exception) {
            _state.value = State.Error(e)
        }
    }
}

3. Эскалация: привлечение третьей стороны

Если диалог зашел в тупик и вопрос принципиальный, я предлагаю привлечь дополнительного эксперта. Это не «нажаловаться», а попытка получить больше экспертизы.

• «Давай спросим у тимлида/архитектора, какой подход лучше вписывается в нашу долгосрочную стратегию».
• «Может, обсудим это на ближайшем митапе команды (tech huddle), чтобы узнать мнение других?»
• «Я создам небольшой сниппет для сравнения двух подходов и покажу его на стендапе».

4. Компромисс и принятие решения

В 90% случаев диалог и аргументы приводят к консенсусу. Но есть ситуации, когда нужно уступить:

• Решение ревьюера не является технически ошибочным, а лишь альтернативным. Иногда скорость и движение вперед важнее идеального кода.
• Ревьюер обладает специфическим контекстом (история багов, планы на будущее), который я могу не знать.
• Вопрос касается соблюдения утвержденных правил команды (линтеры, кодстайл). Здесь лучше просто принять правила игры.

Важный итог: После принятия решения (даже если оно не в мою пользу) я никогда не оставляю саботажа или пассивной агрессии в коде. Я либо вношу правки, либо, если очень переживаю, создаю задачу в трекере на технический долг (tech debt), чтобы вернуться к вопросу позже, с новыми данными. Построение и поддержание отношений доверия и взаимного уважения в команде всегда в долгосрочной перспективе важнее, чем выигрыш в одном конкретном код-ревью.