Изучив миллионы запросов на включение, мы нашли 11, которые тормозят работу вашей команды разработчиков.
31 авг. 2023 г.
|
Pull requests in theory |
Запросы на включение: теория |
|
Pull requests in reality |
Запросы на включение: реальность |
В мире поставок программного обеспечения запросы на включение являются основой сотрудничества между многими командами разработчиков. Тем не менее, хотя запросы на включение имеют решающее значение для обеспечения качества кода и способствуют совместному вводу информации, они также стали основным узким местом в рабочих процессах разработчиков.
Плохо составленные или неправильно управляемые запросы на включение могут обернуться катастрофой для производительности. В ходе бенчмарк-оценки инженерно-технических показателей компании LinearB была проанализирована работа 2000 команд разработчиков, было проверено 4,5 миллионов веток кода и обнаружено следующее:
- среднее время цикла выполнения части работы (первое подтверждение развертывания) составляет 7 дней;
- половина всех запросов на включение не рассматривается (например, над ними никто активно не работает) в течение как минимум 50 % своего жизненного цикла;
- время цикла и время ожидания увеличивается вдвое для запросов на включение из 200 строк кода по сравнению с запросами на включение со 100 строками кода.
Обнаружив столь существенное снижение производительности разработчиков, исследователи выявили причину таких неудовлетворительных показателей производительности.
На основе качественного и количественного анализа разработчики и специалисты по работе с данными выявили четыре основные проблемы в управлении запросами на включение и 11 распространенных типов запросов на включение, которые особенно вредны для эффективности рабочего процесса.
4 основные проблемы инженерно-технических рабочих процессов
- Во многих организациях нет формального процесса назначения запросов на включение (PR).
- Нет никаких инструкций по стандартизации или методических рекомендаций в отношении размера запросов на включение.
- Команды рассматривают всех запросы на включение с одинаковой важностью, несмотря на разные уровни риска.
- Отсутствие понимания контекста запроса на включение или того, сколько времени потребуется на рассмотрение (пока запрос не будет открыт).
После выявления основных проблем неэффективных запросов на включение, инженеры смогли приступить к работе над устранением этого огромного препятствия в рабочих процессах разработчиков. Одним из наиболее перспективных методов решения этой проблемы стало непрерывное слияние — автоматизация классификации запросов на включение с целью оптимизации пути слияния.
11 типов токсичных запросов на включение
Проанализировав 4,5 миллиона веток кода, исследователи LinearB обнаружили, что запросы на включение, вызывающие более 90 % этих узких мест, попадают в 11 отдельных, но смежных категорий.
- Небольшие запросы на включение, вызывающие сущее мученье
Запросы на включение, которые днями томятся во входящих сообщениях, так привычны. Хуже всего, когда эти запросы касаются просто внесения изменений в документацию. Быстрые обновления отвлекают внимание, задерживая выполнение даже самых простых задач.
|
My documentation change waiting get approved |
Изменение, внесенное в мою документацию, ожидает одобрения |
- Запросы на включение с устаревшим кодом
Передача на рассмотрение запроса на включение в устаревший API? Это не просто излишне, это также означает отсутствие синхронности с текущим состоянием системы. Запросы на включение такого типа просто создают перегруженность, приводя к непроизводительным издержкам. - Запросы на включение, требующие подбора и изучения материалов
Запросы на включение без надлежащей документации подобны входу в комнату с завязанными глазами. Без четкой документации проверяющим приходится догадываться о намерениях, что приводит к резкому переключению контекста. - Запросы на включение с высоким уровнем риска без соответствующей поддержки при рассмотрении
Сверхбольшой и потенциально опасный запрос на включение только с одним проверяющим? Это бомба замедленного действия. Учитывая важные изменения, такие запросы на включение в идеале должны просматриваться несколькими проверяющими, чтобы гарантировать точность и безопасность.
|
Watching my PR get merged without the right reviewer |
Смотрю на слияние моего запроса на включение без подходящего проверяющего |
- Запросы на включение с домино-зависимостями
Запросы на включение, отложенные по причине их зависимости от других запросов на включение, могут создать цепную реакцию задержек. Эта последовательная тактика выжидания может стать серьезным препятствием для рабочего процесса. - Непродуманные улучшения
Хорошие запросы на включение имеют четкую цель. Те запросы на включение, которые пытаются решить несколько проблем одновременно, могут сбивать с толку, что приводит к возможным упущениям в ходе проведения проверок. - Запросы на включение с неуправляемым риском, связанным с нарушением безопасности
Что происходит, когда запрос на включение затрагивает конфиденциальные части кода, но не отправляется на проверку вашей команде безопасности? Такой недосмотр может привести к тому, что ваши приложения станут уязвимыми, что представляет серьезную угрозу для организации.
|
Security |
Безопасность |
|
Trunk |
Ж/д магистраль |
|
My PR |
Мой запрос на включение |
- Запросы на включение, которые проходят мимо экспертов команды
В каждой команде есть разработчики, ответственные за поддержание определенных областей кодовой базы. Запросы на включение должны проверяться специалистом в определенной области, не упуская важных отзывов и идей. - Запросы на включение без тестов
Код без тестов похож на спуск на воду лодки, не зная, поплывет ли она. Запросы на включение, в которых отсутствуют соответствующие тесты, могут привести к необнаруженным ошибкам, ставящим под угрозу стабильность приложения. - Запросы на включение с отсутствующим контекстом (ориентировочное время проверки, нечеткое описание и т. д.)
Запрос на включение без указания ориентировочного времени проверки или описательного заголовка может поставить проверяющих в затруднительное положение. Незнание требуемых обязательств может привести к задержкам в рассмотрении запроса.
|
You didn’t pick up my pull request |
Вы не взяли мой запрос на включение |
|
You didn’t add estimated time to review |
Вы не добавили ориентировочное время на рассмотрение |
- Запросы на включение, которые вырезают существующий код
Запросы на включение, удаляющие код, требуют особого внимания. Такие запросы на включение, которые часто проводятся с целью повышения эффективности, могут иметь каскадный эффект, и к ним следует подходить с осторожностью.
Два потенциальных решения проблем, связанных с токсичными запросами на включение
В зависимости от того, на какой стороне дебатов по разработке вы находитесь, вы, возможно, слышали о двух потенциальных решениях проблем, связанных с токсичными запросами на включение:
- Парное программирование. Хотите избавиться от токсичных запросов на включение? Вы можете увеличить практику парного программирования внутри своей организации, предоставив разработчикам возможность работать вместе над кодом, при этом один инженер будет выступать в роли инициатора, а второй будет выступать в роли навигатора или наблюдателя, при этом проверки кода выполняются в ходе работы, а роли меняются по мере необходимости. Хотя парное программирование увеличивает количество человеко-часов, необходимых для доставки программного обеспечения, оно оказывает положительное влияние на уровень дефектности в программном обеспечении. Однако парное программирование также может оказаться сложной задачей для многих команд, особенно в случаях удаленного парного программирования.
Несколько полезных советов по парному программированию от члена сообщества Dev Interrupted Райана Латта. Он рекомендует:
«Поговорите, прежде чем начать работать в паре. Во время таких переговоров должны быть установлены правила, например, как часто вы переключаетесь, и что ожидается от инициатора/навигатора».
Следующим, что не менее важно, является достижение определенного соглашения относительно вашей манеры работы/предпочтений. Отличный вопрос, который можно задать: «Если я увижу, что вы столкнулись с трудностями или совершаете ошибку, когда вы хотите, чтобы я вас поправил и как вы хотите, чтобы я это сделал?»
- Непрерывное слияние. Для многих команд, желающих оптимизировать рабочие процессы проверки кода, внедрение непрерывного слияния может обеспечить значительное улучшение. Непрерывное слияние — это процесс, в котором после выполнения автоматизированных тестов и анализа рабочего процесса изменения кода легко интегрируются в основную ветку на основе программируемых правил.
Исследования показывают, что внедрение gitStream, бесплатного инструмента непрерывного слияния, предназначенного для оптимизации перехода от кодирования к развертыванию, сократило время цикла поставки программного обеспечения на 61,07 %, а время проверки запросов на включение сократилось на 38,14 %. Это происходит благодаря настраиваемым, программируемым рабочим процессам, которые
- Автоматически назначают проверяющих.
- Прикрепляют теги «ориентировочное время проверки» к запросам на включение.
- Классифицируют запросы на включение в зависимости от риска репозитория (низкий, средний или высокий).
- Внедряют функции автоматического одобрения для запросов на включение с низким уровнем риска.
- Создают быстрые защитные механизмы «политики как код».
Как вы решаете проблемы, связанные с запросами на включение?
Исследование запросов на включение понятно: мы выявили важное узкое место в рабочем процессе современных команд разработчиков программного обеспечения. В то время как команда LinearB сосредоточена на разработке инструментов непрерывного слияния для решения этой проблемы, организации используют самые разные подходы в отрасли.
👉 Как ваша команда решает свои проблемы, связанные с запросами на включение? Дайте нам знать, оставив комментарий ниже или отправив ответ по электронной почте.
Как элитные команды разработчиков решали проблемы, связанные с токсичными запросами на включение? Скачайте документ «Непрерывное слияние. Руководство по стандартам слияния: бесплатное руководство по стандартам слияния, которые расширяют возможности политики как кода в элитных организациях».
Документ Непрерывное слияние. Руководство по стандартам слияния описывает недостатки непрерывной интеграции и развертывания программного обеспечения, важность установления стандартов слияния в вашей команде и то, как может помочь автоматизация рабочих процессов LinearB.
Внутри вы найдете
- Анализ философии непрерывного слияния и ее многочисленных преимуществ.
- 13 наших любимых стандартов слияния, обеспечивающих качество и повышающих эффективность