Переключение контекста: что говорят 5 млн PR на GitHub
Данные 5+ млн PR показывают реальную стоимость переключения контекста для разработчиков – и проблема совсем не там, где вы думаете.
By Ellis Keane · 2026-03-29
Стоимость переключения контекста, которую цитирует большинство статей – 23 минуты на восстановление концентрации после прерывания, согласно исследованию Глории Марк в UC Irvine – это реальная находка из реального исследования. Но оно измеряло работников умственного труда в целом в 2008 году, а не инженеров-программистов. А небольшая индустрия блогов, которая умножает 23 минуты на предполагаемое количество ежедневных прерываний (обычно от 6 до 15, в зависимости от настроения автора), чтобы получить тревожные годовые цифры в долларах – всегда в сопровождении стоковой фотографии человека, держащего голову – делает то, что оригинальное исследование никогда не предполагало.
У меня есть личная заинтересованность в этом вопросе. В предыдущей компании я проводил – и это не преувеличение – от 80 до 100 процентов некоторых дней просто как человеческий маршрутизатор. Не писал код, не ревьюил его. Маршрутизировал информацию между людьми и инструментами, потому что ни одна система их не связывала. Этот опыт – часть причины, по которой мы создали Sugarbug, но также и то, почему я скептически отношусь к стандартным калькуляторам стоимости переключения контекста. Они измеряют прерывание. Они не измеряют дни, когда вы никогда не добираетесь до того, от чего должны были отвлечься.
Поэтому мы хотели знать, что переключение контекста на самом деле стоит в инженерной работе – не в абстрактных терминах продуктивности разработчиков, а измеренное в артефакте, который команды производят ежедневно: pull request. Мы синтезировали результаты трёх масштабных исследований, охватывающих более 5 миллионов PR в тысячах проектов с открытым исходным кодом, и посмотрели, что на самом деле определяет время ревью pull request.
Главный вывод: самое дорогостоящее переключение контекста – не уведомление в Slack, которое прерывает вашу работу. Это pull request, который сутки лежит в очереди на ревью, вынуждая автора заново выстраивать весь ментальный контекст, когда вопросы наконец поступают.
Использованные наборы данных
Мы не строили собственный парсер и не анализировали 10 000 PR в изоляции. Мы синтезировали результаты двух рецензируемых исследований и одного большого отраслевого набора данных, а затем проверяли их выводы друг относительно друга.
stat: "3,35 млн" headline: "Pull request, проанализированных Zhang et al." source: "Pull Request Latency Explained: An Empirical Overview (Empirical Software Engineering, 2022)"
Три основных набора данных:
- Zhang et al. (2022), рецензируемое: 3 347 937 закрытых PR в 11 230 проектах. Использована смешанная линейная регрессия с эффектами для выявления причин задержек ревью PR. Опубликовано в Empirical Software Engineering.
- Adadot (2023), отраслевой набор данных: Более 300 000 объединённых PR от ~30 000 разработчиков. Не рецензируемое, но выборка большая, а методология (корреляция тау Кендалла) прозрачна. Фокус на размере PR в сравнении со временем выполнения.
- Исследование множественных ревью (2019), рецензируемое: 1 836 280 PR в 760 проектах GitHub. Опубликовано в Information and Software Technology. Изучает поведение при одновременном ревью – прямой прокси-показатель переключения контекста в ревью кода.
Мы сопоставили эти данные с отчётом DORA State of DevOps 2024 и отчётом Atlassian Developer Experience 2024 (опрос более 2100 разработчиков о переключении контекста, продуктивности разработчиков и человеческой стороне проблемы).
Очередь – настоящий убийца производительности
Zhang et al. обнаружили, что время до получения PR первого ответа – первого комментария, первого ревью, вообще чего-либо первого – объясняет 58,7% дисперсии в общем сроке жизни PR. Это самый сильный наблюдаемый предиктор в наборе данных – опережающий размер PR, сложность кода и количество изменённых файлов! Это несопоставимо.
Основная стоимость переключения контекста при ревью кода – не само переключение. Это очередь, которая формируется, пока все заняты переключением между другими задачами.
Подумайте, что это означает на практике. Инженер открывает PR в 10:00. Назначенный ревьюер погружён в свою собственную ветку фичи, или на встрече, или разбирает сообщения в Slack (и, честно говоря, вероятно, всё три по очереди). PR лежит. К тому моменту, как кто-то берёт его в 15:00, автор давно переключился на что-то другое. Теперь у ревьюера есть вопросы, а значит, автор должен вернуться к коду, который писал пять часов назад, заново выстроить ментальный контекст и ответить. Ответ приходит в 16:30, но ревьюер уже ушёл.
PR стареет ещё на один день.
Данные показывают, что это скорее проблема очередей, а не дисциплины – и стоимость переключения контекста этой очереди накапливается так, что калькуляторы прерываний полностью упускают.
Небольшие PR вас не спасут
Вы слышали это раньше: небольшие PR ревьюятся быстрее, поэтому держите PR маленькими. Это не совсем неверно, но размер эффекта (на самом деле) меньше, чем можно было бы ожидать.
Анализ Adadot более 300 000 PR выявил корреляцию тау Кендалла всего 0,06 между размером PR и временем выполнения – слабая связь, хотя исследование не сообщало доверительных интервалов для агрегированного значения. PR до 100 строк имеют около 80% вероятности завершения в течение недели, что звучит отлично – пока вы не осознаете, что это тот же показатель завершения, что и у PR, шесть дней пролежавшего в чьей-то очереди ревью!
stat: "0,06" headline: "Корреляция между размером PR и временем выполнения" source: "Анализ Adadot более 300 000 PR от ~30 000 разработчиков (2023)"
Более интересное открытие: эта корреляция сильно варьировалась между организациями – от 0,1 до почти 0,7 в зависимости от компании. Что говорит о том, что размер PR сам по себе не является узким местом – узким местом является культура ревью и процесс вокруг PR. Команда с сильной культурой ревью может эффективно работать с более крупными PR. Команда, где ревью – это вторичный вопрос, будет страдать с PR любого размера.
Порог в 400 строк из исследования ревью кода SmartBear/Cisco по-прежнему работает как полезная эвристика – данные Adadot также показали, что вовлечённость в ревью падает за пределами этого диапазона. Но оптимизация размера PR без исправления базовой ритмичности ревью – это, говорю это с искренней симпатией ко всем инженерным менеджерам, которые пробовали, – перестановка шезлонгов на палубе.
Все ревьюят всё одновременно
Исследование множественных ревью обнаружило, что 62% pull request включают разработчиков, одновременно ревьюирующих несколько PR. Что важнее, они нашли статистически значимую корреляцию: большее количество одновременных ревью на одного ревьюера было связано с более длительной задержкой разрешения PR.
62% pull request включают разработчиков, одновременно ревьюирующих несколько PR – и множественное ревью напрямую коррелирует с более длительным временем разрешения. attribution: Исследование множественных ревью pull request, 1,8 млн PR в 760 проектах
Механизм интуитивно понятен (хотя исследование, будучи наблюдательным, не доказывает направление причинно-следственной связи). Ревьюер берётся за PR №1, читает diff, начинает формировать ментальный контекст того, что делает код. Затем приходит уведомление – PR №2 нужно ревьюировать, потому что он блокирует деплой. Ревьюер переключается. Когда он возвращается к PR №1, ему нужно перечитать половину diff, потому что ментальный контекст угас.
Масштабируйте это на команду из восьми инженеров, у каждого два или три открытых PR, каждый ревьюит для двух или трёх коллег – и издержки координации начинают объяснять сами себя. Отдельно отчёт DORA 2024 обнаружил, что кластер «высокоэффективных» сократился с 31% до 22%, а кластер низкоэффективных вырос с 17% до 25%. DORA не выделяет одновременность ревью PR как фактор, но растущие издержки координации – один из правдоподобных вкладов в этот сдвиг.
Что упускают оценки стоимости переключения контекста
Позвольте быть прямым относительно цифры «50 000 долларов на разработчика в год», которая широко распространена в статьях о стоимости переключения контекста. Методология большинства таких оценок: возьмите 23 минуты на восстановление концентрации, умножьте на предполагаемое количество дневных прерываний (обычно от 6 до 15, в зависимости от драматизма автора), умножьте на часовую ставку разработчика и аннуализируйте.
Проблема не в том, что математика неверна. Проблема в том, что она рассматривает все переключения контекста как равнозначные. Переключение с глубокого написания кода на сообщение в Slack с вопросом, где командный обед – это переключение контекста. Переключение с ревью одного PR на ревью другого PR в совершенно другой кодовой базе – это тоже переключение контекста. Но когнитивные издержки несопоставимы, и уравнивание их в единой часовой ставке скрывает, где происходит реальный ущерб.
Конкретно: на последнем месте работы типичный день означал переключение между Notion, Linear, Mattermost, Proton Mail, Proton Calendar, Discord, Twitter, Farcaster и бесчисленными каналами Telegram и Signal – и я уверен, что забываю ещё с полдюжины. Сейчас я использую несколько инструментов (Signal, Obsidian, Figma, GitHub, электронная почта, календари). Стоимость за переключение не изменилась. Изменилось то, сколько контекстов конкурирует за внимание – и какие из них действительно важны.
Данные PR говорят о том, что дорогие переключения – те, которые создают очереди, а не те, которые прерывают поток. Разработчик, которого пингуют для ревью PR немедленно (в течение нескольких минут) и который делает быстрое ревью 50 строк – это короткое прерывание с высокой отдачей. Разработчик, который ставит этот запрос на ревью в очередь вместе с ещё четырьмя и займётся ими завтра – это более длительное прерывание для ревьюера, но создаёт гораздо большие издержки для автора и команды.
Что измеряют калькуляторы издержек
- Индивидуальные прерывания – как часто нарушается чей-то поток
- Время восстановления концентрации – сколько времени нужно, чтобы вернуться к предыдущей задаче
- Умножение часовой ставки – большие и пугающие годовые цифры
Что на самом деле показывают данные PR
- Формирование очереди – PR, ожидающие первого ответа
- Одновременность ревью – ревьюеры, ведущие несколько PR
- Каскадные задержки – переключения контекста автора, накапливающие задержки ревьюера
Что это означает для вашей команды
Если вы хотите снизить стоимость переключения контекста для разработчиков в своей команде, практический ответ скучен – что, вероятно, и объясняет, почему о нём мало пишут. Это не инструмент. Это не процессный фреймворк с программой сертификации. Это ритмичность ревью. (Знаю, знаю. Никто никогда не получал повышение за улучшение ритмичности ревью.)
Инженерные бенчмарки LinearB за 2025 год, полученные из 6,1 млн PR в 3000 организациях, обнаружили, что команды, достигающие элитного времени цикла (менее 2,5 дней), имели одну общую черту: они быстро ревьюировали PR. Не потому что у них было меньше PR, или их PR были меньше (хотя зачастую так и было), а потому что отвечать на запросы ревью в течение нескольких часов было нормой команды, а не второстепенным вопросом.
Для справки: мы с Беном – команда из двух человек – в среднем отвечаем на первый PR за минуты, а не за часы. Это не демонстрация дисциплины (мы не такие). Это командное соглашение: запросы ревью – единственное уведомление, которое не ставится в очередь. Действия CI и автоматизированные тесты обрабатывают механические проверки, что означает, что человеческое ревью – часть, требующая реального контекста – короче и происходит немедленно. Сначала было соглашение. Инструменты просто сделали его устойчивым.
На практике это означает:
- Измеряйте время до первого ответа, а не только время цикла. Если вы отслеживаете метрики DORA, добавьте эту. Это самый сильный предиктор пропускной способности PR (объясняющий 58,7% дисперсии срока жизни согласно Zhang et al.).
- Ограничьте одновременность ревью. Если у ревьюера три ожидающих запроса ревью, четвёртый всё равно не получит хорошего ревью. Данные о множественном ревью показали чёткую связь между одновременностью и задержкой. Начните с лимита WIP в два одновременных ревью и отслеживайте влияние.
- Прекратите оптимизировать размер PR изолированно. Небольшие PR хороши, но не заменяют команду, которая действительно ревьюирует. Команда, производящая двадцать PR по 50 строк в день с 48-часовым бэклогом ревью, находится в худшем положении, чем команда, производящая пять PR по 200 строк с ревью в тот же день.
- Признайте, что ревью – это настоящая работа. Опрос Atlassian 2024 года обнаружил, что 69% разработчиков теряют 8+ часов еженедельно из-за неэффективности. Ревью не должно быть одной из этих неэффективностей – но только если оно рассматривается как первоклассная инженерная деятельность, а не прерывание «настоящей» работы.
И вот часть, которую никто в пространстве инструментов производительности – включая нас, если честно – не хочет говорить вслух: самое эффективное вмешательство для снижения стоимости переключения контекста в инженерных командах – это не инструмент. Это командное соглашение о том, когда ревьюируются PR. Если подразумеваемая норма вашей команды – «займусь ревью, когда будет пауза», никакое количество инструментов не предотвратит каскад очередей, который раскрывают данные PR.
Инструменты помогают – возможность видеть полный контекст PR без открытия четырёх вкладок браузера снижает когнитивную нагрузку на каждое переключение, а выделение того, какие ревью блокируют работу других, помогает с приоритизацией. Но основной рычаг – это соглашение, а соглашения бесплатны. Никакого калькулятора на 23 минуты не требуется.
Самое дорогостоящее переключение контекста – не уведомление, прерывающее ваш поток. Это запрос ревью, который сутки лежит в очереди, вынуждая автора заново восстанавливать ментальный контекст, когда вопросы наконец поступают.
Получайте сигнальную разведку прямо в свой почтовый ящик.
Часто задаваемые вопросы
Q: Сколько стоит переключение контекста для одного разработчика в год? A: Оценки расходятся, но фактические исследования значительно скромнее, чем предполагает большинство статей. Исследование Глории Марк в UC Irvine показало 23 минуты на восстановление концентрации после прерывания, а опрос Atlassian 2024 года среди более 2100 разработчиков выявил, что 69% теряют более 8 часов еженедельно из-за неэффективности. Денежные цифры сильно зависят от допущений по зарплате, частоте прерываний и определения «переключения» – именно поэтому мы сосредоточились на данных PR.
Q: Помогает ли Sugarbug снизить переключение контекста для инженерных команд? A: Да. Sugarbug объединяет такие инструменты, как Linear, GitHub, Slack и Figma, в единый граф знаний, чтобы инженеры могли видеть полный контекст задачи – нужный PR, обсуждение в Slack, комментарий в Figma – не открывая четыре вкладки. Цель – меньше переключений, а не меньше инструментов.
Q: Каков идеальный размер pull request для минимизации задержек ревью? A: Исследование Adadot на основе анализа более 300 000 PR обнаружило, что PR менее 100 строк кода имеют около 80% вероятности завершения в течение недели. Свыше 400 строк качество ревью и скорость завершения падают. Меньшие PR также снижают нагрузку переключения контекста у ревьюера.
Q: Интегрируется ли Sugarbug с pull request на GitHub? A: Да. Sugarbug собирает активность GitHub – PR, комментарии, ревью и изменения статуса – и связывает их с соответствующими сигналами в других инструментах. Если задача в Linear породила PR, а поток в Slack обсуждал подход, Sugarbug автоматически связывает все три.
Q: Откуда берётся статистика «23 минуты на восстановление концентрации»? A: Она взята из исследования Глории Марк в UC Irvine, опубликованного в «The Cost of Interrupted Work: More Speed and Stress» (CHI 2008). Исследование показало, что работникам требовалось в среднем 23 минуты 15 секунд, чтобы вернуться к исходной задаче после прерывания. Стоит отметить, что исследование охватывало работников умственного труда в целом, а не конкретно инженеров-программистов.