Считаете, что проверка кода занимает несколько дней? Проверка кода — неотъемлемая часть выпуска высококачественного кода. Но иногда может показаться, что ваша команда зашла в тупик, если они не расставили приоритеты должным образом.
Проверка кода может стать источником разочарования. Вполне естественно хотеть сосредоточиться на своей собственной задаче и видеть, что обзоры кода отвлекают вас от глубокой работы.
В результате у вас может появиться склонность спешить со списком запросов на вытягивание. Или отложите их до тех пор, пока они не станут угрожать мешать продвижению функции вперед. Но при обоих подходах вы упускаете возможность укрепить культуру своей команды.
Для Дерека Прайора, менеджера по разработке персонала в GitHub, проверка кода — это то, как вы создаете правильную культуру в своей компании.
Рецензирование кода — это дисциплина обсуждения вашего кода с коллегами, которая способствует более высокому стандарту кодирования, — сказал Приор» на RailsConf.
Эти обсуждения кода дают вам представление о вашей команде, поощряют обмен знаниями и стимулируют инновации. Вы не застряли в проверках кода. Они — путь к освобождению.
Проверка кода может быть утомительной. Они могут выявить наши худшие привычки. Но они также могут помочь вам понять потребности вашей команды и наладить более тесные связи.
Создав хорошую культуру проверки кода, вы улучшите культуру своей команды. Вот как это сделать.
1. Найдите узкое место в код-ревью.
Прежде чем вы сможете изменить процесс проверки кода, вы должны понять, где он ломается. В код-ревью всегда есть узкое место. И если вы являетесь основателем или старшим инженером, это вполне можете быть вы.
Разработчики с наибольшим опытом — это те, кто в вашей команде, скорее всего, попросят проверить код. Это много работы. И большой вес. Невыполненные обзоры могут даже блокировать прогресс в других областях, таких как выпуск новой функции.
Возможно, вы уже осознали проблему. Итак, вы начали кого-то тренировать. Но обучение требует времени и доверия. Между тем, ваш портфель пулл-реквестов растет.
Изменения начинаются с признания того, что кто-то в вашей команде несет слишком большую часть бремени. Помните, что старший инженер часто не единственный, кто может проверить фрагмент кода.
Ваша команда хочет большей ответственности. И вы, вероятно, готовы очистить свою тарелку. Так как же облегчить свою ношу и дать им возможность?
2. Оцените отношение и комфорт вашей команды с помощью код-ревью.
Когда вы заметите, что все проверки вашего кода выполняются одним и тем же человеком или небольшим списком людей, Ума Чингунде, вице-президент по разработке в Render, рекомендует задать этот вопрос:
«Все ли чувствуют себя уверенно, проводя код-ревью?»
Даже самые функциональные команды с трудом понимают, как комментировать код-ревью. На ранних этапах переделки процесса проверки кода поощряйте товарищей по команде помнить, что за кодом стоит человек.
Гергели Орос, разработчик блога и информационного бюллетеня The Pragmatic Engineer, считает, что эмпатия играет большую роль в лучшей культуре проверки кода.
Начните с признания того, что члены вашей команды все еще могут изучать ваши рекомендации или части кода. Затем он рекомендует сосредоточиться на «объяснении альтернативных подходов» и представлении обзоров, которые «очень позитивны по тону, отмечая первые несколько изменений в кодовой базе, которые предлагает автор».
Есть много причин, по которым члены вашей команды не берутся за проверку кода. Вы не узнаете почему, пока не спросите. Вот как Ума предлагает разобраться в происходящем.
«Если кто-то в команде не просматривает, поговорите», — сказала Ума. «Вы можете сказать: «Я заметил, что вы не проверяете». Возможно, они не чувствуют себя уверенно или не понимают ценности».
Ответ вашего товарища по команде позволит вам узнать, нужно ли вам посмотреть, как вы общаетесь, делитесь знаниями или назначаете проверки кода. Спойлер: все вышеперечисленное.
3. Хорошая коммуникация начинается с четких и лаконичных пулл-реквестов.
Неоднозначность — это быстрый способ отвлечься от проверки кода. Наилучшие результаты — будь то обзоры кода или мозговой штурм — достигаются при задавании четких, осмысленных вопросов.
Команда Palantir в сообщении в блоге о передовых методах проверки кода разработала практический метод оптимизации процесса проверки кода.
«Отправляйте только полные, самостоятельно проверенные (путем сравнения) и самопроверенные CR», — отмечает команда Palantir. «Чтобы сэкономить время рецензентов, протестируйте внесенные изменения (т. е. запустите набор тестов) и убедитесь, что они прошли все сборки, а также все тесты и проверки качества кода как локально, так и на серверах CI, прежде чем назначать рецензентов. ”
Потратьте время, чтобы поймать вещи, которые очевидны. Вы облегчите рецензенту доступ к тому, что важно, и вам будет полезно узнать о проблемах, которые вы не можете решить самостоятельно.
Для Prior запрос на вытягивание — это открытие диалога. Автор запроса предоставляет контекст — он предлагает два абзаца (сосредоточив внимание на том, что вы узнали) для каждого изменения — чтобы помочь рецензенту понять, почему был сделан данный выбор кода. Это объяснение также имеет отношение к будущим обсуждениям, потому что оно становится частью коммита.
Рецензент кода, в свою очередь, должен «задавать вопросы, а не предъявлять требования». Формулируя потенциальные изменения в виде вопросов, вы поощряете дискуссию, которая оставляет место для разных точек зрения и дает возможность поделиться знаниями о том, почему данная идея может быть лучшим путем вперед.
4. Отслеживайте, сколько времени занимает проверка кода.
По мере того, как вы начинаете вовлекать больше членов своей команды в процесс проверки кода, все может естественным образом замедлиться.
Итак, что делать, если проверка кода занимает слишком много времени? Ума считает, что сейчас самое время еще раз связаться с вашими инженерами.
«Если люди слишком долго пишут обзоры, это потому, что они слишком заняты своими делами? Или это потому, что им трудно просматривать код?»
Обычно это некоторая комбинация других обязанностей и неясных ожиданий, которые могут привести к замедлению темпов проверки кода. Чтобы преодолеть эту инерцию, вам придется намеренно выделить время в расписании вашей команды и переоценить то, как вы назначаете код-ревью.
5. Оптимизируйте свое расписание, используя точки паузы для проверки кода.
Проверка кода не должна снижать производительность. Выстраивая время вокруг естественных точек паузы, вы можете избежать нарушения вашего потока и затрат на переключение контекста. Выделите 30 минут до обеда или после утреннего стендапа для проверки кода.
Регулярное время, отведенное для отзывов, сводится к минимуму, и начинает формироваться привычка. Вы можете даже использовать все, что будет дальше — эспрессо или прогулку по кварталу — в качестве награды за завершение обзора кода, пока вы устанавливаете эту привычку.
Эта стратегия — способ эффективно использовать время, когда вы уходите от совещаний или заканчиваете глубокую работу. Если это следует за совещанием, проверка кода может даже начаться с короткого диалога с автором пулл-реквеста, чтобы дать вам дополнительный контекст или акцент помимо того, что было напечатано.
6. Назначьте проверки кода, чтобы установить ожидания для вашей команды.
Ваша команда может исходить из того, что проверка кода не входит в их обязанности. Недостаточно попросить кого-то внести свой вклад, чтобы разрушить это предположение. Вы должны поручить проверку кода каждому члену вашей команды, чтобы было понятно, что это общая ответственность.
Существует несколько способов структурирования заданий. Вот две идеи, которые могут сработать для вашей команды: объединяйте инженеров вместе для выполнения задач, чтобы вам не требовались отдельные проверки, или назначайте проверки через систему ротации.
Пары — полезная конструкция, потому что они облегчают диалог. И вам не нужно явно назначать кого-то для обзора. Вы пишете каждую часть логики парой — один человек «за рулем» (печатает), а другой человек читает и обсуждает свой код. Неизбежно будет больше общих идей и разных подходов.
Вы представляете партнера, чтобы ускорить темп игры. Во время сопряжения у вас автоматически появляется встроенная проверка кода, когда вы пишете код вместе. Это знание — что кто-то поддержит вас — также снимает стресс от ощущения, что вы должны со всем справляться.
В настоящее время мы оцениваем автоматическое назначение проверки кода. Автоматическая ротация назначений помогает как автору запроса на вытягивание, так и правопреемнику. Убедитесь, что у членов команды есть четкий способ сообщить всем, будь то в Slack или где-либо еще, что они заявили о проверке кода.
Автоматизированная система снижает утомляемость ваших инженеров при принятии решений. Это устраняет ощущение, что проверка кода может быть бременем и затратами на попытки вспомнить, кого вы в последний раз вызывали для задания проверки. Возможно, самое главное, он поддерживает культуру рецензирования кода, давая понять, что каждый примет участие.
Вы всегда можете добавить параметр для отмены автоматического назначения, если вам нужен кто-то в вашей команде с определенными навыками для проверки вашего кода.
Создание устойчивой культуры проверки кода способствует продуктивным дебатам и неожиданным выводам. Командное владение кодом укрепляет отношения, разрешая конфликты и предотвращая выгорание.
Ваша команда может обойтись без четко определенного процесса проверки кода. Но установление четких практик и ожиданий в отношении проверки кода может помочь вашей команде лучше распределить нагрузку и продвигаться вперед более плавно и эффективно.
Фото renee_ek на Unsplash.
Cara Borenstein is Co-Founder and CEO at Stashpad - note-taking that feels like messaging. She previously worked in engineering at Twilio and is an alum at Columbia University.
