Разрешение конфликтов

Ситуация:
Author: «Используем кэш Redis для этой операции»
Reviewer: «Не нужно, достаточно database-level кэширования»

Оба мнения обоснованы, но противоречат.

Ситуация:
Author: «list comprehension короче и понятнее»
Reviewer: «Предпочитаю обычный for loop, читаемее»

Вкусовщина, нет объективно правильного ответа.

Ситуация:
Author: «Это оптимизация, можно сделать потом»
Reviewer: «Нужно исправить сейчас, это blocking»

Разное понимание срочности.

❌ «Мне кажется, так лучше»
✅ «Давай замерим производительность обоих подходов»

Author создаёт benchmark:
- Без кэша: 100ms
- С кэшем Redis: 20ms
- С database кэшем: 50ms

Решение на основе данных: используем Redis

1. Author пишет RFC документ
   - Проблема
   - Предлагаемое решение
   - Альтернативы
   - Trade-offs

2. Команда обсуждает (асинхронно или на встрече)

3. Вносятся правки в RFC

4. Принимается решение (автор, тимлид, голосование)

5. Реализация следует согласованному RFC

Уровень 1: Автор и рецензент обсуждают напрямую
Уровень 2: Привлекается senior разработчик / тимлид
Уровень 3: Архитектурный комитет (для крупных решений)
Уровень 4: Технический директор (для стратегических решений)

Author: «Понимаю твою озабоченность производительностью. 
         Я сделал benchmark: текущий подход 100ms, с кэшем 20ms. 
         Считаю, что сложность оправдана.»

Reviewer: «Спасибо за данные! Убедил, LGTM.»

Reviewer: «Я предпочитаю for loop, но понимаю, что это вкусовщина. 
           Если team convention допускает list comprehension — не возражаю.»

Author: «Спасибо за гибкость! В нашем style guide list comprehension 
         разрешён для простых случаев.»

Author: «Ты ничего не понимаешь, это стандартный паттерн!»
Reviewer: «Сам дурак, код ужасный!»
*спор на 50 комментариев*

✅ Спор > 20 комментариев без прогресса
✅ Токсичное поведение с любой стороны
✅ Блокировка критичного PR > 24 часов
✅ Эскалация от автора или рецензента

1. Прочитать дискуссию полностью
2. Понять аргументы обеих сторон
3. Принять решение с обоснованием
4. Написать в PR:

«Спасибо за дискуссию! Понимаю обе позиции:
- Author: производительность важнее (20ms vs 100ms)
- Reviewer: сложность кэша не оправдана

Решение: используем кэш для этой операции, так как 
это критичный путь с высокой нагрузкой. Добавляем 
мониторинг hit rate для оценки эффективности.

Author: пожалуйста, добавь мониторинг в этом PR.
Reviewer: спасибо за внимательный review!

✅ Style guide с примерами
✅ Architecture decision records (ADR)
✅ Best practices документ
✅ Regular calibration sessions

Раз в месяц команда собирается:
1. Берут 3-5 закрытых PR
2. Каждый оценивает замечания: blocking / important / nit
3. Обсуждают расхождения
4. Фиксируют договорённости

Результат: консистентные ожидания от review

Author в описании PR:
«Спорное решение: использую кэш Redis. 
Обсудили на планировании, что производительность 
важнее сложности. Готов обсудить альтернативы.»

Это предотвращает сюрпризы и задаёт контекст.