Устали от обзоров медленного кода? Прочитай это

Руководство для бывшего технического руководителя по созданию здоровой культуры проверки кода, которая поможет вам быстрее выпускать код.

TL;DR

🏎 Узнайте, как ускорить процесс проверки кода, чтобы повысить свою продуктивность.
🔬 Изучите лучшие практики, с которыми я столкнулся для рецензентов кода
✏️ Изучите лучшие практики, с которыми я столкнулся для авторов запросов на вытягивание.

Представьте это.

Вы только что реализовали функцию и написали все тестовые примеры. Вам понравился код, поэтому вы открыли запрос на извлечение и сообщили своим коллегам. По прошествии нескольких дней ваш запрос на вытягивание выглядел точно так же, как и раньше. С виду нетронутый. Без комментариев. Нет запроса на изменение. Вы снова попросили своих коллег проверить код, и они согласились. Прошла еще неделя, и ничего не произошло. Вы спросили еще раз, и они сказали вам, что им нужно больше времени, потому что это был не маленький PR, и нужно было многое принять во внимание.

Наконец, вы увидели уведомление о запросе на изменение и сразу ухватились за него. После разрешения конфликтов слияния и исправления пограничных случаев вы снова запросили проверку и стали ждать. Еще один запрос на изменение появился через несколько дней, и вы снова повторяете процесс. Вы получили одобрение после очередной ревизии, и PR наконец-то был объединен с транком.

Через 4 недели с момента открытия PR.

Если вы можете относиться к этому, вы не одиноки. Многие команды столкнулись с таким медленным процессом проверки кода. По сути, это один из главных блокираторов в цикле разработки. Поэтому я хочу поделиться с вами лучшими практиками проверки кода, которым я научился, чтобы ускорить разработку и помочь вам быстрее выпускать код.

Пойдем.

Для авторов пулреквестов

Первое, чему я научился, чтобы повысить продуктивность проверки кода, — быть вдумчивым как автор. Помимо создания чистого кода, есть много мелких вещей, которые вы можете сделать, чтобы помочь вашим рецензентам заранее понять ваши запросы на вытягивание.

Будь водителем

Вы, автор, являетесь водителем темпа. Зная, что вы полагаетесь на своих коллег в процессе проверки кода, вы можете заранее четко сообщить когда и что, чтобы согласовать ожидания.

когда – это наиболее важная информация, потому что она сообщает рецензентам, насколько это срочно. Рецензенты могут соответствующим образом планировать свою работу. Это отличный способ установить временные рамки для процесса рецензирования, а также отличный способ проявить уважение к времени ваших коллег.

Чтобы сообщить что, обязательно включите PR-описание, которое поможет вашим рецензентам понять цель и структуру кода ваших изменений. Вместо того, чтобы перечислять функциональные возможности, начните с вводного абзаца, объясняющего предысторию и то, почему этот PR необходим, чтобы помочь рецензентам построить свои ментальные модели. Другие описания, которые я считаю очень полезными:

Диаграммы дизайна кода: скриншот вашей высокоуровневой структуры кода помогает рецензентам просмотреть общий дизайн и быстро отреагировать на ваш запрос на вытягивание.
Критерии приемлемости: список простых предложений, таких как "Письмо с подтверждением отправляется пользователю после отправки формы", помогает при проверке найти отсутствующие функции и тестовые примеры.

Будьте лаконичны

Легче всего читать небольшие, ориентированные на лазер пулл-реквесты. Насколько мал? Google Engineering Practices говорит: Невозможно сделать его достаточно маленьким. Исследование показало, что качество код-ревью снижается по мере увеличения количества изменений кода. Чем дольше ваши рецензенты просматривают за раз, тем меньше дефектов они обнаруживают. Поэтому важно, чтобы ваш запрос на вытягивание был небольшим и был сосредоточен на чем-то одном. Если разрабатываемая вами функция слишком велика, вы можете разделить ее на несколько запросов на вытягивание, используя метод сложенного запроса на вытягивание.

Он заменяет большой запрос на включение последовательностью небольших запросов на вытягивание. Это помогает рецензентам сосредоточиться на чем-то одном и прекрасно согласуется с принципом непрерывной интеграции и непрерывной доставки.

Для рецензентов кода

Будьте внимательны к предубеждениям

Исследование, опубликованное Google в 2022 году, показало, что авторы запросов на вытягивание сталкивались с различными уровнями отказа, которые варьируются в зависимости от демографических данных авторов. По данным, они нашли, что

- Женщины столкнулись с вероятностью отказа на 21% выше, чем мужчины.

- Разработчики Black+ столкнулись с шансами на 54% выше, чем разработчики White+

- Разработчики Latinx+ столкнулись с шансами на 15% выше, чем разработчики White+

- Разработчики из Азии+ столкнулись с шансами на 42% выше, чем разработчики из Белого+

- Пожилые разработчики сталкивались с более высокими шансами отказа, чем молодые разработчики.

Нам следует быть более внимательными к непреднамеренным предубеждениям, особенно на разнообразном рабочем месте. Зная об этом, мы можем избежать ненужных откатов при проверке кода и помочь ускорить процесс.

Это отличное место для обучения, а не для снобизма

Независимо от вашего уровня опыта, работа разработчиком предполагает постоянное обучение. Запрос на включение — бесценная площадка для общения разработчиков и обмена отзывами. Поэтому убедитесь, что это место, где вас уважают, и всегда стремитесь к обмену знаниями.

Для меня это всегда было прекрасным поводом узнать о предметной области. Возьмите мой PR в Руководстве по стилю JavaScript Airbnb. Я так много узнал о Спецификации языка ECMAScript от члена Ecma TC39. Если бы он отклонил мою просьбу без конструктивной обратной связи, момент обучения никогда бы не наступил.

Бездействие — это плохо

Год назад я читал запись в блоге под названием Агрессивная проверка кода от технического руководителя Instagram. Он утверждал, что эффективная проверка кода состоит из

решительные действия как можно скорее
стремление снизить цену ошибок
требуя небольшой запрос на вытягивание и двигаясь быстро

Что меня освежило в его подходе, так это то, что отказаться от запроса на вытягивание нельзя. Это сводит к минимуму время на рассмотрение, и это было очень полезно для меня и моей команды. Мы можем поставлять быстро, потому что мы предпринимаем активные действия по проверке кода. Мы не позволяем ожидающим запросам на вытягивание задерживаться и рассматривать с учетом бизнес-кейса.

Последние мысли

Обобщить лучшие практики запросов на вытягивание и проверки кода для ускорения цикла разработки.

установить четкую информацию о когда и что в запросе на вытягивание
создать небольшой и автономный запрос на вытягивание, который фокусируется на чем-то одном
помните о предубеждениях
уважительно относиться к автору и коллегам-рецензентам
принять решительные меры по пересмотру как можно скорее