# 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 фичи

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

# Нужно выяснить какую бизнес-логику писал разработчик

Об этом могут рассказать разработчик, менеджер или таска в 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 вы увидели токсичное поведение одного из ревьюеров; например, сарказм, грубость. Нужно ли с этим что-то делать? Если да, то что?

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

# Теория

# Статьи

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

# Видео

Automating code reviews

← Работа с багами Управление инцидентами →