Как запрос на извлечение может быть больше, чем просто чтение кода
Запросы на вытягивание существуют уже некоторое время. В рамках гибкого процесса они стремятся уменьшить запах кода, узнать мнение других разработчиков и сохранить согласованность кодовой базы.
Это, конечно, чистая утопия. На самом деле PR — это большие куски кода, которые вы собираетесь прокручивать в поисках ошибок.
Недостатки пулреквестов
Отсутствие контекста
Основная проблема PR — полное отсутствие контекста. В большинстве случаев ваш инструмент запросов на вытягивание покажет вам фрагменты кода, которые изменились, и скроет неизмененные строки. Это скрытие удаляет контекст, который вам нужен для полного обзора кода.
Вы, конечно, можете увидеть этот скрытый код, но обычно его не так легко прочитать, и он делает его более запутанным, чем должен быть.
В конце концов, вы все еще можете обнаружить запах кода и плохие практики, но вы на самом деле не можете сказать, будет ли код работать хорошо! И это может быть способом подталкивания ошибок.
Огромное количество кода для проверки
PR может ощущаться как длинная страница, которую вы просто прокручиваете. И чем больше вы прокручиваете, тем больше вы теряете внимание, так как вам хочется вернуться к своим задачам.
PR — это не забавный процесс, и если они слишком длинные (а они быстро заканчиваются), некоторые рецензенты просто потеряют терпение, быстро пролистают PR и одобрят его.
Опять же, это может привести к ошибкам и запаху кода в вашей кодовой базе. А ты этого не хочешь!
Как улучшить код-ревью?
Здесь я использовал выражение Проверка кода. Причина в том, что PR должен привести к процессу, большему, чем просто прокрутка страницы. Это должен быть процесс, в ходе которого другие разработчики понимают и усваивают новый код, а не просто ищут плохие методы.
Создайте PR на ранней стадии процесса разработки
Первым улучшением процесса проверки кода является создание запросов на вытягивание на ранней стадии в процессе разработки и пометка их как WIP (В разработке). .
Поступая таким образом, вы сможете легко запросить ранние отзывы от своих товарищей по команде и позволить им понять новую функцию одновременно с ее разработкой. Кроме того, у рецензентов будет меньше кода для проверки за один раз, и они будут сосредоточены на каждом этапе PR.
Потяните за ветку и вперед!
Если первое улучшение было реализовано, рецензенты уже должны лучше понимать эту функцию. Однако иногда кода недостаточно для визуализации изменений. Таким образом, ваши рецензенты могут захотеть потянуть ветку и попробовать.
Использование нового решения может принести множество преимуществ.
Во-первых, рецензенты будут визуализировать изменения и смогут говорить об этом от имени разработчика, внесшего изменения. Как часть команды, некоторые менеджеры ожидают, что каждый член будет делиться знаниями, в том числе тем, над чем работают другие.
Кроме того, в случае демонстрации, если разработчик, работавший над задача не может уделить этому внимание, один из рецензентов может легко взять демонстрацию и уже знает тему.
Наконец, быстрое тестирование новой функции рецензентами сэкономит время специалистам по обеспечению качества, поскольку первый шаг тестирования.
Связать рабочий элемент с PR
Это может показаться банальным, но привязка рабочего элемента (или описания задачи) к PR сделает контекст более понятным. Рецензенты могут открыть его и прочитать перед тем, как начать рецензирование, и у них будет лучшее представление о том, о чем идет речь.
Чем больше тем лучше!
Вы можете захотеть, чтобы несколько рецензентов проверили ваш код. А если у вас может быть несколько профилей (юниоры, средние и взрослые), это еще лучше!
Юниоры могут задавать вам вопросы о вашем новом коде, это может быть своего рода наставничество, и от этого выиграет вся команда.
У среднего и старшего звена могут быть различные взгляды на передовой опыт, и можно было бы начать дискуссию по улучшению глобального качества кода.
Также хорошо иметь разные точки зрения на случай, если кто-то из рецензентов пропустит ошибку!
Вывод
Для меня запрос на вытягивание может быть настолько же эффективным, насколько и трудоемким, в зависимости от того, как организован процесс.
Но, применив к ним некоторые простые улучшения, можно улучшить командную работу, наладить общение между разными членами команды и улучшить всю кодовую базу.
Не следует пренебрегать PR, это может быть очень сильный процесс.