Code review – это проверка исходного кода на ошибки, проблемы архитектуры.
Помогает:
- Найти баги
- Выявить проблемы в архитектуре
- Сделать код единообразным
А также, что более важно в долгосрочной перспективе:
- Это работающий инструмент для обратной связи
- Участники code review будут учиться на своих и чужих ошибках
- Для оценки hard skills разработчика
- Code review поможет делиться знаниями о технологиях, вариантах решения проблем, возможных проблемах и самом проекте в команде
- Даёт приток новых идей для улучшений в процессах, подходах и автоматизации
- Децентрализация знаний
Будет плохо продукту:
- Баги на production. Тестирование не найдёт все баги
- Технический долг снежным
комомлавиной накрывает проект. Время разработки новых фич увеличивается экспоненциально - Подходы и архитектура будут несогласованны. Получится Франкенштейн.
Будет плохо lead-у:
- Плохо знает hard skills разработчиков по отдельности
- Не может оценить производительность
Будет плохо разработчикам:
- Без адекватной обратной связи будет ощущение работы "в стол". Демотивация, депрессия, поиск новой работы
- Не будет притока новых знаний о:
- Проблемах, с которыми уже столкнулись другие. Учиться на чужих ошибках – это быстро и дёшево
- Технологиях
- Вариантах решения проблем
- Самом проекте
В 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) разработчик может додумать ваши эмоции. Старайтесь быть ближе, как минимум – созвонитесь.
- Выяснить, какую бизнес-логику писал разработчик
- Рассмотреть ключевые элементы бизнес логики, архитектуру решения
- Углубиться в детали
Об этом могут рассказать разработчик, менеджер или таска в jira. Feedback выдаётся разработчику и/или менеджеру при проблемах с бизнес-логикой.
Чтобы прокачать этот скилл можно пройтись по задачам с описанием.
Чтобы получить косячные задачи, можно:
- Зайти в "achieved"
- Попросить придумать косячные задачи
- Или попросить придумать задачи косячного менеджера
Результат – понимание задачи или аргументы что не так с задачей. Возможно – список на исправление.
Об архитектуре решения и ключевых моментах расскажет разработчик. Feedback нужно выдать ему же.
Практиковаться можно на merge request вместе с разработчиком.
Разработчик самостоятельно расскажет о проблемах, если его спросить. Также он сможет аргументировать, почему он выбрал определённое решение.
Результат – понимание и принятие или аргументы:
- Почему это нужно исправить
- Что будет, если не исправить
- Соглашение с разработчиком как исправить
На проекте должен быть linter. Он проверяет отступы, использование необъявленных переменных и другую головную боль.
Если это необходимо – пройдитесь по деталям реализации.
Результат – статус задачи "review закончено" или аргументированный список правок.
В зависимости от целей ревью и времени на него:
- Наиболее критичные задачи
- Практики безопасности
- Архитектуру
- Задачи junior devs
- Все задачи
- Выбранное вами
Вы должны чётко осознавать, что именно и зачем вы ревьюите.
Для ускорения процесса нужно настроить проверку кода на:
- Синтаксические ошибки
- Стилистические неточности
- Предполагаемые ошибки во время исполнения (использование необъявленной переменной и тд)
- Возможные уязвимости в коде и используемых библиотеках
Это поможет сократить время на поиск проблем вручную.
Не полагайтесь на память. 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 вы увидели токсичное поведение одного из ревьюеров; например, сарказм, грубость. Нужно ли с этим что-то делать? Если да, то что?
Раскрывают тему: