Этот пост является частью серии из 7 постов на тему Как создать культуру обучения для групп разработчиков ПО:

№ 8 Код-ревью

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

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

  • Размер проверяемого кода слишком велик (несколько сотен строк кода), что сделает обзор поверхностным и с незначительной добавленной стоимостью;
  • За проверку кода отвечает один человек (как правило, профиль технического руководителя). Помимо задержки, это может привести к усталости и повторению, что приведет к разочарованию людей, запрашивающих проверку.

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

Таким образом, если проверка кода является отличной поддержкой для передачи знаний, мы наблюдаем явный недостаток капитализации. Если обзор не зависит от какого-либо инструмента, обычно используются функции Pull/Merge Request (PR/MR), предлагаемые GitHub, GitLab, BitBucket или Azure Devops, позволяющие получить обзор внесенных изменений и добавить комментарии. После завершения рецензирования и закрытия PR/MR их содержание и комментарии, как правило, не переносятся на потом.

Таким образом, есть еще области для улучшения, чтобы оптимизировать эту практику. Первый подход, который обычно применяется, состоит в чередовании роли рецензента внутри команд, избегании концентрации на одном человеке и усилении коллективного владения кодом. В дополнение к расширению обмена знаниями, это позволит оптимизировать процесс доставки ценности. В самом деле, какая жалость тратить два дня на разработку функции, а затем ждать три дня, пока кто-то, наконец, не сможет вычитать код (не говоря уже о возможных исправлениях, которые нужно будет вычитывать!).

#9 Сеансы парного и мобильного программирования

Метод совместного творчества, пропагандируемый Экстремальным программированием, заключается в парном программировании, в котором участвуют два разработчика, которые будут вместе работать над поставленной задачей. Один человек за клавиатурой и один руководит и корректирует в режиме реального времени, и все это со сменой ролей через равные промежутки времени (например, 10 минут). Данная методика имеет ряд преимуществ:

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

Как и обзор кода, он имеет сильное социальное измерение и укрепляет общение и сплоченность команды.

Его расширение, Моб-программирование, пригласит несколько человек из команды или даже всю команду. Если ваши команды не знакомы с этим упражнением, имейте в виду, что это не проблема, если вы не будете заниматься программированием Peer/Mob ежедневно. Не все задачи разработки подходят. Разработка основных бизнес-функций будет хорошей игровой площадкой, где незначительное исправление может быть менее актуальным.

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

С практической точки зрения, особенно после эпидемии COVID-19 и распространения удаленной работы, инструменты для совместной разработки в режиме реального времени становятся все более популярными. Можно упомянуть Visual Studio LiveShare, плагин для VisualStudio или Code With Me, предложенный редактором JetBrains.

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