Когда вы пишете код, перерывы действительно - отстой.
Вы находитесь в зоне, высоко летите, убивая ее. И БАМ… встреча, стендап, * вставьте прерывание * ... Отлично!
В этом контексте ревью кода можно рассматривать как еще одно препятствие на пути к производительности.
И, честно говоря, я понимаю это.
Проверка кода - это сложно.
Вам нужно не только прекратить то, чем вы сейчас занимаетесь, вам также необходимо погрузиться в чужой код. Чтобы переключить внимание, требуется много энергии.
Проверка кода требует времени.
Согласно опросу Slack Overflow за 2019 год, 56,4% разработчиков тратят 4 часа и более в неделю на проверку кода. И это может составлять до 20% рабочей недели разработчика!
Проверка кода разочаровывает.
Отправителю может быть неприятно получить отклонение запроса на вытягивание и ждать несколько часов, если не дней, для рассмотрения. Для рецензента рецензирование кода может казаться препятствием на пути к хорошему продуктивному дню.
Да, проверка кода иногда может быть сложной, трудоемкой и утомительной.
Но они также являются хорошим способом, среди прочего, поделиться знаниями, предотвратить ошибки и укрепить корпоративную культуру.
Далее следует манифест для отправителей и рецензентов, призванный вернуть спокойствие при проверке кода. 🙏
Манифест отправителя
Вот что вы, как отправитель, можете сделать, чтобы повысить свои шансы на своевременное одобрение запросов на вытягивание.
Отправьте, когда закончите.
Я знаю, это звучит очевидно. Но дело в том, что большую часть времени, если машина не работает, это не потому, что она сломана, а потому, что она не подключена к розетке!
Очень мелкие детали могут иметь большое значение для восприятия вашей работы. И вы не хотите, чтобы ваши коллеги чувствовали, что они вкладывают время и силы в проверку кода незавершенной работы.
Я: «Просто пропал ‹/div›!»
Вы: «Да, я знаю, но все это не сработало, и мне потребовалось 20 минут, чтобы это заметить».
Итак, вот что вы можете сделать:
- Выполните самопроверку кода. Включите WIP в заголовок или ярлык, если вы еще не закончили.
- Самостоятельная проверка кода. Используйте отчет о различиях в редакторе кода или инструменте управления версиями, чтобы выявить ошибки.
- Убедитесь, что тесты вашего CI зеленые, прежде чем назначать рецензента, это сэкономит им время.
Делайте меньшие запросы на вытягивание
Я понимаю, это большая, важная и сложная функция, и у вас может возникнуть соблазн отправить длинный запрос на перенос. Тем не менее, в большинстве случаев вам лучше отправлять небольшие запросы на вытягивание.
Проверка кода требует энергии. Еще больше проверок большого кода. Не навязывайте своей команде вызов разработчик против еды каждый раз, когда они проверяют ваш код.
Будьте любезны, разрежьте его на более мелкие куски. Вы также делаете себе одолжение:
- Вы получите более качественную обратную связь. Чем дольше запрос на вытягивание, тем меньше качественных отзывов на каждую строку кода вы получите. Сделайте свой пул-реквест небольшим (не слишком маленьким), и вы увеличите свои шансы получить по нему отличную обратную связь.
- Вы получите их одобрение быстрее. Это беспроигрышный вариант: разбив свою работу на более мелкие запросы на включение, вы увеличиваете свои шансы на их более быстрое одобрение.
Для ботаников - это исследование, проведенное командой программистов Cisco. Это показывает, что после 400 LoC способность находить дефекты значительно снижается. 🤓
Следующий принцип помогает контролировать размер запросов на вытягивание.
Сузить рамки
Объем вашего запроса на перенос должен быть простым, уникальным и четко определенным. Это может быть функция, пользовательская история или исправление ошибки.
Можно подумать, что рецензенты имеют ограниченное количество «кредитов» (как и все). Каждый раз, когда они на чем-то сосредотачиваются, они используют 1 балл. Что произойдет, когда у них останется 0?
LGTM 👍
Сделайте все возможное, чтобы уменьшить шум вокруг вашей работы. Помните об объеме внимания рецензента.
Например, избегайте недействительных изменений (например, пропуска строк). Они не добавляют ценности и не усложняют проверку кода.
Точно так же, если ваш запрос на перенос изменяет поведение, не включайте изменения в форматирование. И наоборот, если ваш запрос на вытягивание изменяет форматирование, не включайте изменения, которые влияют на поведение. Рецензент может их не заметить.
Дайте контекст
Считайте свой пул-реквест документацией для новичков. Направляйте читателя контекстом.
Начните с понятного названия.
Затем напишите четкое описание, чтобы объяснить, что вы делаете и почему вы это делаете. Какова цель этого запроса на перенос? Почему это изменение необходимо? Как вы подошли к этой проблеме?
Описание также является отличным местом, чтобы указать на нерешенные проблемы и открытые вопросы. Рецензенты могут предложить вам разблокировать вас.
Вы работаете над видимой частью продукта? Скриншоты помогут быстрее изложить вашу точку зрения.
- Показать различия до и после.
- Используйте цветные стрелки.
- Добавьте записи экрана, если хотите :)
Наконец, напишите информационные знаки по пути, чтобы помочь рецензенту обосновать ваши рассуждения.
Сохраняйте чистую историю коммитов , чтобы рецензенту было легче следовать вашим шагам. Используйте комментарии, чтобы указать на альтернативы, которые вы изучали.
Приветственный отзыв 🎁
Отказ - это больно.
По правде говоря, отказ от кода причиняет еще больше вреда.
Все нормально. Не принимай это на свой счет.
Комментарии и предложения - это возможность научиться и стать лучшим инженером-программистом 😉
Манифест рецензента
Поздравляю с этим! Теперь давайте рассмотрим несколько принципов, которые помогут вам стать лучшим рецензентом 😎
Примите правильный образ мышления
Нет сценария, при котором команда может извлечь выгоду из грубого или покровительственного отношения рецензента. Будьте любезны. Период.
Хотите сделать рецензирование кода более увлекательным?
Найдите что-нибудь, что вы можете узнать из этого обзора. Новая библиотека, новый метод, новая концепция, более простой способ делать что-то. Какие знания вы извлечете из этого?
Если вы более опытный разработчик, чем вы можете поделиться? Как вы можете использовать этот обзор, чтобы передать знания отправителю? Как вы можете помочь им стать лучшими инженерами-программистами?
Как на самом деле сделать обзор кода
Что посмотреть
Что мне вообще нужно искать? Без четких указаний о том, что и как проверять, легко заблудиться. Вот что ты можешь сделать.
Прежде всего, проверьте цель. Выполняет ли этот код то, для чего он предназначен? Есть ли в новом коде части, которые вам непонятны? Задайте уточняющие вопросы. Код легко тестируется? Попробуй это. Нет необходимости выходить за рамки, если этот квадрат не отмечен.
Хорошо, теперь, когда код работает, пора сосредоточиться на реализации.
Подумайте, как бы вы подошли к этой проблеме. Вы бы поступили иначе? Есть ли потенциал для рефакторинга или абстракции? Это новое изобретение колеса? Используется ли это стандартные шаблоны кода?
Что не проверять
Поскольку фрагмент кода нуждается в улучшении, это не всегда означает, что его нужно улучшать.
В конце концов, проверка кода - это компромисс между качеством и скоростью, и в зависимости от масштабов и стадии проекта, возможно, имеет смысл оставить несколько вещей позади. .
Точно так же вы не должны делать вещи, которые можно автоматизировать. Пусть ваш любимый линтер найдет недостающие точки с запятой и дополнительные отступы. Нет необходимости в бесконечных спорах о табуляции и пробелах.
Наконец, не увеличивайте объем запроса на перенос. Если вы думаете о новых вещах, которые необходимо сделать, создайте новый запрос / задачу на перенос, если на то пошло.
Своевременно проверять
Есть как минимум 3 веские причины просматривать запросы на вытягивание в часы, а не дни.
- Отправитель может быстрее перейти к следующей задаче
- Это снижает стоимость переключения контекста
- Это снижает риск конфликтов слияния между ветвями.
Отказ от ответственности: я только что выпустил GitRise, инструмент, который помогает командам, использующим GitHub и Slack, быстрее проверять запросы на вытягивание. Я действительно думаю, что это может помочь с этим :)
Как оставить отзыв при обзоре кода?
При обратной связи форма имеет такое же значение, как и содержание.
Знаете ли вы, что в письменном общении нейтральный контент выглядит более негативным, чем есть на самом деле? Остерегайтесь этой предвзятости и включайте смайлики, когда это необходимо, чтобы получить правильный тон в ваших комментариях.
Кроме того, в большинстве случаев, даже если вы почти уверены, что есть лучший способ сделать что-то, лучше задать вопрос, а не запрашивать изменение. К тому же вопросы звучат менее агрессивно.
Наконец, вознаградите, когда все сделано правильно. Проверка кода также является отличным местом, чтобы воздать должное коллегам за хорошую работу. Будьте креативными и веселыми :)
👏 Поздравляем, вы дочитали до конца эту запись в блоге!
🙏 Большое спасибо за чтение и дайте мне знать, если у вас есть какие-либо комментарии!
🌱 Я только что выпустил GitRise, инструмент, который создает напоминания о запросах на вытягивание для команд, использующих Slack и GitHub. Попробуйте, если хотите. Жду ваших отзывов.
