Внедрение здорового мышления при проверке кода в вашу команду

«Проверка кода» — это момент в процессе разработки, когда вы (как разработчик) и ваши коллеги работаете вместе и ищете ошибки в последнем фрагменте кода, прежде чем он будет выпущен. В такой момент вы можете быть либо автором кода, либо одним из рецензентов.

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

В этой статье я расскажу, как можно изменить этот результат, изменив свое мышление во время проверки кода:

• Как команда
• Как автор
• Как рецензент

Работа в команде

Развивайте культуру сотрудничества

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

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

Включите проверки кода в свои оценки

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

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

Экономьте время с помощью руководств и автоматизации

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

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

Остаться студентом

Любой может сделать код-ревью, и каждый должен получить код-ревью — независимо от уровня старшинства. С благодарностью принимайте любые отзывы как возможность учиться и делиться знаниями. Рассматривайте любую обратную связь как открытую дискуссию , а не защитную реакцию. Как говорит Райан Холидей:

«Любитель защищается. Профессионал находит обучение (и даже, иногда, появление на публике) приятным; им нравится, когда им бросают вызов и унижают, и они занимаются образованием как непрерывным и бесконечным процессом. (...)”

— Райан Холидей, Эго — враг

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

Искусство выбора рецензентов

На мой взгляд, выбор рецензентов — одно из самых важных решений для эффективной и здоровой проверки кода в команде.

Допустим, ваш коллега отправляет код-ревью и решает отметить «всех», потому что бессознательно он/она может захотеть ускорить процесс, предоставить наилучший код или убедиться, что все знают об изменении кода. Каждый из рецензентов получает уведомление, затем открывает ссылку PR и видит множество людей, отмеченных как рецензенты. В их голове всплывает мысль «кто-то другой это сделает», что приводит к игнорированию кода и закрытию ссылки.

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

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

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

Имейте сочувствие

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

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

Знайте, как идти на компромисс

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

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

Личные проверки кода

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

Учитесь на результатах проверки кода

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

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

Как автор

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

Установите раннее общение

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

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

Следуйте рекомендациям

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

Будьте вашим первым рецензентом

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

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

Потерпи

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

Будьте слушателем

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

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

Как рецензент

Планируйте заранее

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

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

Поддержите

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

Проверьте ветку и запустите ее

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

Спросите, прежде чем предположить

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

Большинство вопросов относятся к этим двум типам категорий:

1. Вопросы «как»
   Если вы не понимаете, как что-то работает или что оно делает, оцените вместе с автором, достаточно ли ясен код. Не путайте простой код с невежеством. Есть разница между кодом, который трудно читать, и кодом, о котором вы не знаете. Будьте открыты для изучения и использования новой языковой функции, даже если вы еще недостаточно хорошо ее знаете. Однако используйте его только в том случае, если он упрощает кодовую базу.
2. Вопросы «почему»
   Когда вы не понимаете «почему», не бойтесь предлагать прокомментировать код, особенно если это крайний случай или исправление ошибки. Код должен быть самоочевидным, когда дело доходит до объяснения того, что он делает. Комментарии являются дополнением к объяснению того, почему определенный подход. Объяснение контекста очень ценно, когда речь идет о ремонтопригодности, и это убережет кого-то от удаления блока кода, который считался бесполезным. (Лично я предпочитаю комментировать код до тех пор, пока не почувствую себя в безопасности, чтобы не забыть его позже.)

Конструктивная критика

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

• Открытые обсуждения.
  Избегайте формализовать свой отзыв как команду или обвинение, например, «Вы должны…» или «Вы забыли…». Выразите свой отзыв в виде открытого обсуждения, а не обязательной просьбы. Не забывайте комментировать код, а не автора. Если комментарий не о коде, то ему не место в обзоре кода. Как уже было сказано, поддержите. Использование пассивного залога, использование множественного числа, высказывание вопросов или предложений — хорошие способы подчеркнуть сопереживание автору.
  

Вместо «Извлечь этот метод отсюда…» лучше выбрать «Этот метод следует извлечь…» или «Что вы думаете об извлечении этого метода…»

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

Неясно: «Этот код должен быть…».

Мнение: «Я считаю, что этот код должен быть…»

Факт: «Следуя [нашим рекомендациям], этот код должен быть…».

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

Мнение: «Я считаю, что этот код может быть…»

Объяснение: «Я считаю, что этот код может быть (…), потому что это улучшит читаемость и упростит модульные тесты».

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

Помимо того, что скажите что-то вроде «Использование фильтра поможет нам [мотивировать]», также скажите: «В этом случае это может быть что-то вроде: [фрагмент кода]. Вы можете проверить [пример на Finder.js]. Если у вас есть сомнения, не стесняйтесь пинговать меня в Slack».

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

Держите фокус

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

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

Установить ожидания

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

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

Научитесь отказываться от проверки кода

Хотя никто в этом не признается, иногда приходится отказываться от code review. В тот момент, когда вы принимаете код-ревью, но пытаетесь поторопиться, качество проекта оказывается под угрозой, а также мышление вашей команды.

Когда вы соглашаетесь просмотреть чужой код, этот человек доверяет вашим возможностям — это обязательство. Если у вас нет времени быть рецензентом, просто скажите «нет» своему коллеге (коллегам). Я действительно имею это в виду; не позволяйте своим коллегам ждать проверки кода, которая никогда не будет сделана. Не забывайте общаться и четко выражать ожидания . Будьте честны со своей командой и, что еще лучше, с самим собой. Что бы вы ни выбрали, делайте это с пользой для здоровья и правильно.

Заключение

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

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

Дальнейшее чтение на SmashingMag:

• Совместная работа: как дизайнеры и разработчики могут общаться, чтобы создавать лучшие проекты
• Улучшение совместной работы за счет вовлечения дизайнеров в процесс проверки кода
• Какие подкасты стоит слушать веб-дизайнерам и разработчикам?
• Как составить идеальное резюме веб-разработчика