С 14 по 27 июня пройдет онлайн-конференция для тимлидов Podlodka Teamlead Crew!

# Code review

# Описание

Code review – это проверка исходного кода на ошибки, проблемы архитектуры.

# Почему code review важен?

Помогает:

  • Найти баги
  • Выявить проблемы в архитектуре
  • Сделать код единообразным

А также, что более важно в долгосрочной перспективе:

  • Это работающий инструмент для обратной связи
  • Участники code review будут учиться на своих и чужих ошибках
  • Для оценки hard skills разработчика
  • Code review поможет делиться знаниями о технологиях, вариантах решения проблем, возможных проблемах и самом проекте в команде
  • Даёт приток новых идей для улучшений в процессах, подходах и автоматизации
  • Децентрализация знаний

# Что будет, если не делать code review?

Будет плохо продукту:

  • Баги на production. Тестирование не найдёт все баги
  • Технический долг снежным комомлавиной накрывает проект. Время разработки новых фич увеличивается экспоненциально
  • Подходы и архитектура будут несогласованны. Получится Франкенштейн.

Будет плохо lead-у:

  • Плохо знает hard skills разработчиков по отдельности
  • Не может оценить производительность

Будет плохо разработчикам:

  • Без адекватной обратной связи будет ощущение работы "в стол". Демотивация, депрессия, поиск новой работы
  • Не будет притока новых знаний о:
    • Проблемах, с которыми уже столкнулись другие. Учиться на чужих ошибках – это быстро и дёшево
    • Технологиях
    • Вариантах решения проблем
    • Самом проекте

# На кого можно делегировать code review?

В code review желательно участвовать всем разработчикам проекта.

# Примеры поведения

# Примеры плохого поведения

  • Токсичное поведение
    • Переход на личности
    • Сарказм
    • Раздражение
  • Плохо настроенные процессы
    • Неизвестно, кто должен делать code review
    • Неизвестны критерии прохождения. Процесс может продолжаться бесконечно
    • Список правок не разбит на группы по приоритетам
    • Разработчик долго ожидает code review
    • В merge request приходят огромные фичи
  • Software используется недостаточно эффективно
    • Не настроены linter-ы и/или автоматические тесты
    • Разработчики пытаются запомнить список правок
  • Разработчику непонятно, зачем нужно вносить правки
  • Ревьювер не читал задачу в Jira

# Примеры хорошего поведения

  • Адекватная обратная связь
    • Уточняющие вопросы вместо прямого указания на ошибки
    • Нейтральность или доброжелательность
  • Процессы помогают ускорить и упростить code review
    • Разработчики понимают, что в их интересах делать code review
    • Все знают список требований для прохождения code review
    • Список правок удобным образом приоритизирован. Например, с помощью emoji 🔥, 💬
    • Обратная связь – быстрая, в идеале – в течение дня
    • Merge requests атомарные
  • Для ускорения используются библиотеки и программы
    • Используются linter-ы и автоматические тесты
    • Разработчики не пытаются запоминать список правок в уме
  • Участники code review согласны и понимают причины почему нужно внести правки
  • Ревьювер знает бизнес-логику решаемой задачи

# Способы прокачки

# Практика и способы прокачки

Code review выглядит просто. Проверяете merge request на ошибки и пишете о них, но есть нюанс. Важно понять и принять, что это долгосрочный процесс. Настоящие причины ошибок – пробелы в знаниях, сниженная мотивация. Lead должен включать soft skills, чтобы не стрелять в ногу себе и команде.

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

# Умение критиковать

Умение критиковать – это ключевой навык.

# Как смягчить критику вербально:
  • Задавать уточняющие вопросы вместо прямого указания на ошибки
  • Сперва похвалить, затем – критиковать
  • Хвалите, если всё хорошо
  • Feedback от разработчика о том как прошло review. Да, взять и спросить
  • Не говорите "ТЫ сделал плохо"

Практиковаться можно "в уме" на merge request. Когда поняли что научились – давать настоящий feedback.

# Как смягчить критику невербально:
  • Следите за эмоциональными состояниями: своим и разработчика

Практикуйтесь "в уме" на косячных merge request. Вы не должны злиться и раздражаться на "эти тупые ошибки 😡". Для настоящих review начинайте с хороших merge requests и постепенно переходите к косячным.

Чтобы не злиться самому помогут:

  • Понимание себя и истинных причин раздражения
  • Понимание что цель не найти баги, а обучить разработчика не делать их снова; или помочь разработчику сменить позицию или компанию на более подходящую
  • Психолог
  • Успокоительное
  • Просто будьте проще, от ваших багов навряд ли кто-то пострадает (с) Капитан Очевидность

Понять что разработчик устал, ненавидит вас, могут помочь:

  • Практические книги по психологии
  • Психологические тренинги
# Дополнительно

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

# Процесс review фичи

  1. Выяснить, какую бизнес-логику писал разработчик
  2. Рассмотреть ключевые элементы бизнес логики, архитектуру решения
  3. Углубиться в детали
# Нужно выяснить какую бизнес-логику писал разработчик

Об этом могут рассказать разработчик, менеджер или таска в jira. Feedback выдаётся разработчику и/или менеджеру при проблемах с бизнес-логикой.

Чтобы прокачать этот скилл можно пройтись по задачам с описанием.

Чтобы получить косячные задачи, можно:

  • Зайти в "achieved"
  • Попросить придумать косячные задачи
  • Или попросить придумать задачи косячного менеджера

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

# Рассмотреть ключевые элементы бизнес логики, архитектуру решения

Об архитектуре решения и ключевых моментах расскажет разработчик. Feedback нужно выдать ему же.

Практиковаться можно на merge request вместе с разработчиком.

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

Результат – понимание и принятие или аргументы:

  • Почему это нужно исправить
  • Что будет, если не исправить
  • Соглашение с разработчиком как исправить
# Углубиться в детали

На проекте должен быть linter. Он проверяет отступы, использование необъявленных переменных и другую головную боль.

Если это необходимо – пройдитесь по деталям реализации.

Результат – статус задачи "review закончено" или аргументированный список правок.

# Что ревьюить

В зависимости от целей ревью и времени на него:

  • Наиболее критичные задачи
  • Практики безопасности
  • Архитектуру
  • Задачи junior devs
  • Все задачи
  • Выбранное вами

Вы должны чётко осознавать, что именно и зачем вы ревьюите.

# Настройка и использование software

# Автоматическая проверка кода

Для ускорения процесса нужно настроить проверку кода на:

  • Синтаксические ошибки
  • Стилистические неточности
  • Предполагаемые ошибки во время исполнения (использование необъявленной переменной и тд)
  • Возможные уязвимости в коде и используемых библиотеках

Это поможет сократить время на поиск проблем вручную.

# Комментарии

Не полагайтесь на память. Git хостинги дают комментировать участки кода, вести дискуссии. Критичные правки можно записывать например в комментарии к merge request.

Можно настроить автоматическую синхронизацию комментариев с мессенджером.

# Интеграции
  • Git хостинги умеют слать на почту сообщения, связанные с code review
  • Можно добавить интеграцию через API, чтобы слать сообщения в мессенджер
    • О новых merge requests
    • Об утверждённых merge requests
    • О merge requests которые долго никто не проверял
    • Комментариях к коду

# Работа с другими процессами

  • CI/CD. Если встроить code review в процесс CI/CD, то на выходе можно будет получать более надёжный продукт

# Вопросы для собеседования

  • Blitz
    • Что такое code review?
    • Организован ли у вас в команде code review?
    • Может ли code review помочь найти баги, которые не может найти тестировщик?
  • Вопросы "на подумать"
    • Какие плюсы даёт code review в общем и вашей команде?
    • Можно ли не делать code review? В каких случаях?
    • Сколько времени можно тратить на code review?
    • С какими процессами в команде можно интегрировать code review?
    • Во время code review вы увидели токсичное поведение одного из ревьюеров; например, сарказм, грубость. Нужно ли с этим что-то делать? Если да, то что?

# Консультации

# Теория

# Статьи

Раскрывают тему:

# Видео