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

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

Недостатки пулреквестов

Отсутствие контекста

Основная проблема PR — полное отсутствие контекста. В большинстве случаев ваш инструмент запросов на вытягивание покажет вам фрагменты кода, которые изменились, и скроет неизмененные строки. Это скрытие удаляет контекст, который вам нужен для полного обзора кода.

Вы, конечно, можете увидеть этот скрытый код, но обычно его не так легко прочитать, и он делает его более запутанным, чем должен быть.

В конце концов, вы все еще можете обнаружить запах кода и плохие практики, но вы на самом деле не можете сказать, будет ли код работать хорошо! И это может быть способом подталкивания ошибок.

Огромное количество кода для проверки

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

PR — это не забавный процесс, и если они слишком длинные (а они быстро заканчиваются), некоторые рецензенты просто потеряют терпение, быстро пролистают PR и одобрят его.

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

Как улучшить код-ревью?

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

Создайте PR на ранней стадии процесса разработки

Первым улучшением процесса проверки кода является создание запросов на вытягивание на ранней стадии в процессе разработки и пометка их как WIP (В разработке). .

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

Потяните за ветку и вперед!

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

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

Связать рабочий элемент с PR

Это может показаться банальным, но привязка рабочего элемента (или описания задачи) к PR сделает контекст более понятным. Рецензенты могут открыть его и прочитать перед тем, как начать рецензирование, и у них будет лучшее представление о том, о чем идет речь.

Чем больше тем лучше!

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

Юниоры могут задавать вам вопросы о вашем новом коде, это может быть своего рода наставничество, и от этого выиграет вся команда.

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

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

Вывод

Для меня запрос на вытягивание может быть настолько же эффективным, насколько и трудоемким, в зависимости от того, как организован процесс.

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

Не следует пренебрегать PR, это может быть очень сильный процесс.