Раньше мы писали о том, как поощряем пул-реквесты с менее чем 100 дополнениями. В этом блоге мы подробно рассмотрим, откуда взялось руководство и как оно работает на практике.
Происхождение
Стоит отметить, что управление количеством строк в запросе на вытягивание само по себе не является целью, а скорее средством для достижения цели.
В основном нас беспокоит количество концепций.
Хотя пул-реквест должен иметь достаточно контекста, чтобы быть понятным, мы обнаружили, что ограничение общего количества концепций имеет несколько преимуществ:
Сниженный риск блокировки
Чем больше операций выполняется в запросе на перенос, тем выше вероятность блокировки.
Например, запрос на вытягивание, содержащий рефакторинг, введение нового шаблона, и реализацию новой функции одновременно, рискует застрять, если возникнут вопросы по любому из них.
Разделив рефакторинг на новый запрос на перенос, его можно отправить, просмотреть и объединить отдельно. Точно так же можно обсудить новый шаблон в другом запросе на перенос.
Более безопасное развертывание
В нашей настройке слияние с основной веткой запускает автоматическое развертывание в производственной среде.
Ограничение количества кода, который выпускается за один раз, сокращает количество вещей, которые могут пойти не так, и гарантирует, что целевой откат будет легко выполнить, если он станет необходимым.
Повышение качества обзора
Время и пропускная способность рецензентов ограничены, и чем больше им нужно принимать во внимание и давать отзывы за раз, тем менее у них будет возможность сделать это осмысленным образом.
Это может привести к тому, что ключевые детали будут упущены или даже пропущена проверка и «сделаем это позже».
Ранняя коррекция курса
Просмотр запроса на вытягивание, содержащего полностью завершенную функцию, и обнаружение лучшего пути, который можно было бы выбрать несколькими коммитами ранее, - болезненная ситуация для всех.
Совместное использование (даже незавершенных) результатов на ранней стадии помогает обнаруживать проблемы или альтернативные решения и на раннем этапе достичь консенсуса.
Скорость проверки
Тесно ограниченный пул-реквест с меньшим количеством кода для чтения помогает рецензентам быстрее справиться с ним и делает его более привлекательным для восприятия.
Опираясь на ограничения
Такая работа требует дисциплины и осознания того, как и когда делиться кодом с командой.
Ограничение «100 добавлений» работает как руководство и напоминание, этого должно быть достаточно, чтобы заставить вас остановиться и подумать.
100 зарекомендовал себя как золотая середина для проверки, может ли быть проблема или есть лучшая альтернатива для обнаружения.
Это не значит, что не бывает случаев, когда оправдан более крупный запрос на вытягивание (и в равной степени можно наполнить запрос на вытягивание несколькими концепциями в нескольких строках кода).
Вот почему мы в конечном итоге поощряем такое поведение, а не делаем его строгим правилом.
Мы тонко стимулируем такое поведение, заставляя наш бот для проверки уведомлять рецензентов о небольших запросах на вытягивание в специальном канале чата:
В более крупных запросах на вытягивание упоминания будут опущены, и они будут найдены через почтовый ящик GitHub.
Это не означает, что вы не получите обзора, если у вас более 100 дополнений, но предполагает, что, хотя запрос на включение ‹100 будет рассмотрен в течение нескольких часов (иногда даже минут), для чего-то большего может потребоваться немного больше времени. .
Оставаясь на курсе
Как и в случае с любой метрикой, люди могут упустить из виду намерение и чрезмерно сосредоточиться на самой метрике.
Вот несколько общих индикаторов этого:
Проблема: искусственное разделение уже написанного кода, чтобы он оставался ниже отметки добавления 100 таким образом, чтобы упустить требуемый контекст для проверки (примером может быть отправка только миграции уже письменная модель).
Решение. Рассмотрите возможность пересмотра стиля разработки, например, используя нисходящий подход или прогрессивное улучшение, чтобы избежать проблемы в первую очередь, или отклонитесь от рекомендаций, когда это имеет смысл.
Проблема: использование неприемлемых обходных путей, например удаление разрывов строк, которые улучшали читаемость, чтобы не выходить за рамки ограничения.
Решение. Качество и удобочитаемость кода всегда должны иметь приоритет над любыми рекомендациями. Как и в случае с нашим ограничением длины строки в 120 символов, цель состоит в том, чтобы оказать достаточное давление на код, чтобы предложить лучший код, а не идти на компромиссы для достижения числовой цели.
Проблема: цепочка непроверенных запросов на вытягивание, зависящих друг от друга, накапливается.
Решение. И отправители, и рецензенты несут ответственность за обеспечение жесткого цикла проверки. Публикация своей работы в удобной форме помогает ускорить работу рецензентов, которые со своей стороны обязуются проводить рецензирование своевременно.
Однако это балансирующее действие, позволяющее ограничить прерывание и одновременно разблокировать других, поэтому, если кто-то окажется в ситуации запуска третьего зависимого запроса на вытягивание, подумайте о том, чтобы вручную отправить команду ping для получения помощи.
Хотя для этого требуется особый образ мышления и дисциплина, простое присутствие этого ограничения привело к заметному улучшению сроков проверки, качества и нескольким нововведениям в том, как мы работаем.
