Короткий ответ Нужно пересмотреть процесс так, чтобы глубина и формальность ревью соответствовали реальному риску изменения (критичный путь оплаты против мелкой правки текста), распределить нагрузку шире одного human bottleneck и дополнить ревью автоматическими проверками там, где это возможно. Как это работает подробнее При росте команды фиксированное правило «один ревьюер на всё» перестаёт масштабироваться: количество PR растёт линейно с числом разработчиков, а пропускная способность ревью — не обязательно. Решение обычно сочетает несколько механизмов: назначение ревьюеров по владению кодом (CODEOWNERS) вместо случайного выбора, автоматизацию рутинных проверок (линтеры, статический анализ, security-сканеры) до ревью человеком, и дифференциацию строгости ревью по риску (двойное ревью для платежей, одно для внутренних инструментов). Пример кода Что использовать на практике Практика. Важно явно определить SLA на ревью (например, первый отклик в течение рабочего дня) и сделать его видимым в метриках команды, ин
Загрузка…
