Иногда бывает так, что вы отправляете на проверку пул-реквест, который оказался существенно больше, чем вы ожидали. И у вас возникает вопрос:
«Какого же размера он должен быть? Бывает ли идеальный размер? Если бы теоретически можно было полностью его контролировать, то насколько большим его нужно делать?»
Вы гуглите, находите множество ресурсов, сайтов и статей наподобие этой, которые анализируют тему и делают примерно такой вывод:
«Слишком маленькое количество строк может не отображать полностью изменения, а чрезмерно большой PR может утомить проверяющих, что усложнит выявление проблем или написание осмысленного отзыва»
И хотя вы понимаете логику автора, в то же время осознаёте, то теоретический ответ может быть лишь смутным, что «серебряной пули» не существует. Как всегда, в жизни всё сложнее.
Однако моя статья будет немного о другом:
«Мы проанализируем PR примерно 30 тысяч разработчиков, чтобы проверить, как размер PR коррелирует с временем внедрения, полученными комментариями и отказами во внесении изменений, чтобы найти статистически наилучший размер и понять, что на него влияет.»
Пояснение: тем, кто экспериментирует с данными, особенно если они прошли курсы/обучение в сфере данных, приведённое выше может напомнить о фразе «Корреляция не означает причинно-следственной связи». Да, они будут абсолютно правы. Мы попытаемся рассмотреть под разными углами, как эта корреляция варьируется в зависимости от компании, разработчика и общего объёма коммитов кода, а также под другими углами, которые могут помочь нам понять, какие другие значения могут по каким-то причинам отвечать соответствующим паттернам. Однако это «всего лишь» числа и корреляции, они не объясняют своих причин, поэтому любые наши предположения о причинах, скорее, субъективны и не подтверждены научными исследованиями.
Методология
Время внедрения
В данном случае мы считаем время внедрения (lead time) как время от первого события PR (или первого коммита, или открытия PR) до момента мерджа PR.
Подготовка данных
Данные, которые были удалены как выбросы:
PR со временем внедрения более шести месяцев
PR со временем внедрения менее пяти минут
Изменения в файлах более 20 тысяч строк
PR с изменениями в более чем 20 тысячах строк
Выполнив такую фильтрацию, мы получили несколько сотен тысяч смерженных пул-реквестов, которые и использовались для создания представленного ниже анализа.
Алгоритм
Все корреляции были рассчитаны по методике тау Кендалла, которая должна лучше оценивать корреляцию в случае нелинейных соотношений.
Как время внедрения соотносится с размером PR
Прежде чем углубляться, нужно сказать, что интуитивно мы ожидаем, что размер PR тем или иным образом коррелирует со временем внедрения, но так ли это? Проведя расчёт корреляций между двумя переменными для всего датасета, мы получили в результате следующую матрицу корреляции.
По этим числам можно сказать, что некая корреляция между двумя переменными, похоже, присутствует, но она ненамного выше предела статистической незначимости. Это означает следующее:
Корреляция между ними присутствует, но она не очень велика, вероятно, меньше, чем можно было бы ожидать.
Похоже, нам нужно глубже разобраться, почему эта корреляция выглядит такой слабой; к сожалению, составление графика зависимости количества изменений в строках ко времени внедрения никак не делает картину понятнее; хотя тренд как будто намекает, что PR с более высоким временем внедрения имеют в среднем чуть больший размер, мы видим, что связь между ними не так уж очевидна.
Если немного изменить график, сгруппировав примеры данных по дням и взяв медиану от общих изменений по дням, то мы немного чётче начинаем видеть их взаимосвязь и потенциальное объяснение не очень высокой корреляции.
Это даёт понять. что малое время внедрения относится к PR со стабильно низким количеством изменений строк, а при их увеличении растёт и время внедрения. Однако рост времени внедрения может быть вызван любым размером PR и корреляция между ними очень низка.
Какой размер лучше всего
Чтобы попробовать ответить на этот вопрос, мы должны задаться вопросом, что это значит для нас, то есть что мы стремимся оптимизировать. Это вопрос с бесконечным количеством вариаций. Мы изучим, каков наибольший размер PR, который статистически лучше по трём критериям:
Низкое время внедрения
Большое количество комментариев (не слишком большой для надлежащей проверки)
Низкий уровень отказов/откатов (то есть PR ничего не ломает)
Составив тепловую карту вероятностей внедрения PR за количество недель к размеру, мы получим следующее:
Это значит, что PR с менее чем сотней строк кода имеет вероятность примерно 80% быть внедрённым за первую неделю
Аналогичная тепловая карта для количества комментариев:
Это значит, что PR из шести тысяч строк кода имеет ту же вероятность получить 0 комментариев, как и из пятидесяти строк кода.
Тепловая карта вероятностей откатов:
Это значит, что в общем случае PR большего размера имеют повышенную вероятность отката частей кода (откат означает неисправность этого кода)
Если мы наложим графики вероятностей внедрения PR за одну неделю, вероятности получения одного или более комментариев и вероятность отсутствия отката коммита из этого PR, то получим следующую картину:
Следовательно, статистически, PR с менее чем примерно 400 строками кода имеет хорошую вероятность получения комментариев, внедрения за одну неделю и отсутствия проблем в коде.
Разумеется, это справедливо лишь «статистически» и зависит от множества аспектов. Давайте рассмотрим некоторые из потенциальных причин.
Как это зависит от пользователя
Потенциально можно ожидать, что этот показатель варьируется в зависимости от пользователя, но нам любопытнее узнать, насколько сильно он может разниться для каждого пользователя, будь то автор или ревьюер. Мы убрали всех пользователей, удовлетворяющих хотя бы одному из следующих показателей:
Меньше десяти смерженных PR
Меньше десяти коммитов
Изменено меньше ста строк кода
И всех ревьюеров, имеющих:
Меньше десяти утверждённых и смерженных PR
Мы выполнили анализ корреляции между временем внедрения и размером PR для каждого пользователя. Затем мы составили гистограммы результатов анализа, показывающую, какое количество пользователей имеет каждое из значений корреляции, получив следующие графики:
Корреляция между временем внедрения и размером PR сильно зависит от автора PR, а также от ревьюера PR
Существует широкий спектр потенциальных причин этого, например уровень опыта, процессы в компании/команде, язык программирования, инструмент для проверки и так далее.
Ниже показана взаимосвязь корреляции и количества строк кода, которое разработчик написал за последние шесть месяцев. Хотя инстинктивно мы можем подумать, что это свидетельствует об «опытности» разработчика, на самом деле это может быть и не так, потому что на это тоже влияет множество факторов, например количество совещаний, менторство, время, ежедневно уделяемое совместной работе и так далее.
Тем не менее, мы составили график на случай, если кому-то это покажется интересным. Стоит также отметить, что разница в корреляции между пользователем с большим и малым количеством смерженных PR не очень велика.
Чем больше строк написал разработчик, тем больше коррелирует размер PR со временем внедрения. Это может значить и то, что в таком случае время внедрения становится более предсказуемым и сильнее зависит от размера PR, а не от других параметров (например, сложности). Однако, чтобы установить это, требуется дополнительный анализ.
Зависит ли это от компании
Выше мы говорили о том, что может существовать множество потенциальных причин корреляции между временем внедрения и размером PR, также упомянув, что причина силы корреляции тоже будет многовариантной. Одна из потенциальных причин — это процессы в компании/команде. Если это так, то следует ожидать варьирования корреляции в зависимости от компании.
Взяв небольшую выборку компаний и изучив силу этой корреляции, можно прийти к выводу, что это предположение справедливо, поскольку мы видим, что оно колеблется от 0,1 (отсутствие взаимосвязи между двумя метриками) до почти 0,7 (достаточно сильная корреляция).
Похоже, взаимосвязь размера PR и времени внедрения сильно зависит от компании.
Меняются ли значения со временем
Да, и очень сильно! К сожалению, довольно сложно отобразить всё это на одном графике. Чтобы понять, насколько сильно, взгляните на мой собственный график корреляции от времени.
