Код-ревью для middle и senior разработчиков

Зачем нужно код-ревью

Руководители и менеджеры по инжинирингу знают, что важной частью жизненного цикла разработки ПО является проведение код-ревью (Code Review, CR).

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

Важность для middle и senior разработчиков

В ходе процесса Code Review разработчик проверяет чужой код на наличие ошибок и соответствие рекомендациям, чтобы убедиться в готовности к внедрению.

Ревьюер должен хорошо разбираться в своей области, обладать необходимыми знаниями, чтобы замечать ошибки или пробелы, знать best practices, уметь давать обратную связь сжато и емко.

Как правило, рецензии попадают в компетенцию middle и senior-специалистов. Иногда процесс формализуют и отдают компетенции тем, кто прошел внутреннее обучение и стал экспертом в предметной области программирования.

Подготовка к код-ревью

Процесс обзора пройдет эффективнее, если планировать следующие шаги до погружения в контрольный список проверки:

• Определение целей. Какую проблему должна решить реализуемая функция?
• Проверка компиляции и тестирования. Код, который не прошел проверки на компиляцию и модульные тесты, может

• Ознакомление со связанной задачей, в которой описывается проблема и ресурсы для решения. Это даст

Планирование процесса код-ревью

Важный принцип в работе ревьюера — «от общего к частному».

Планирование процесса обзора состоит из следующих шагов.

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

Оценка архитектуры. Именно на этом важном этапе можно выявить грубые ошибки.

Обзор отдельных функций. На этом этапе проверяется эффективность используемых алгоритмов и методов, каким образом они отразятся на итоговом продукте.

Комментарии для программиста. Здесь важно кратко и доступно объяснить необходимость исправлений, дать полезный совет, подсказать оптимальное решение.

Выбор инструментария

Время старших разработчиков, которые обычно занимаются CR, стоит дорого. Поэтому рекомендуют частично снизить эту нагрузку на сеньора с помощью инструментов и онлайн-сервисов оценки.

Инструменты помогают автоматически собирать измененные файлы и отображать различия. Они упрощают передачу отзывов и общение через комментарии, а также предоставляют, например, статическое тестирование безопасности приложений (SAST) для выявления и устранения уязвимостей.

Лучший вариант использования инструментов — рассматривать их как расширения ревью code и дополнять ими другие типы проверки. Рассмотрим наиболее популярные сервисы.

Reshift — инструмент, который помогает находить и устранять уязвимости перед отправкой результата работы в продакшн. Кроме поиска проблем Reshift помогает соответствовать требованиям регуляторов в отношении разработки ПО.

Collaborator — сервис, направленный на контроль за изменениями, определением проблем, созданием правил и уведомлений. Интегрируется с 11 разными SCM и IDE, предоставляет персонализированные отчеты.

GitLab — сервис оптимизирует обзор и одобрение кода через централизацию процессов. Отличительная особенность инструмента заключается в возможности вложения файлов, тематических обсуждений, запросов на массовое редактирование.

Проведение код-ревью

Итак, новый код написан либо внесены изменения в существующий. Теперь программисту нужно предоставить его для рассмотрения коллегам, которые анализируют структуру, логику, проверяют соответствие стандартам кодирования, оценивают качество.

Основной критерий ревью: код должен быть понятным.

Как правильно проводить код-ревью

Рассмотрим лучшие практики CR.

1. Разумный обзор по размеру и длине. Проверка за один сеанс считается эффективным, когда направлен больше на количество, чем на качество.

В Smartbear провели исследование и обнаружили, что за сеанс программистам следует проверять не более 200–400 строк и тратить не более 60–90 минут.

2. Сравнение со стандартами. Стоит полагаться на стандарты кодирования в команде, а не на личные предпочтения, чтобы получить максимальную пользу от обзоров.
3. Конструктивный фидбек. Важно сосредоточиться на улучшении code, избегать расплывчатых комментариев и осуждения автора. Краткие и четкие практические советы помогут внести полезные изменения.
4. Регулярная замена ревьюеров, чтобы не попасть в ловушку использования одних и тех же разработчиков в качестве рецензентов.
5. Контрольный список обзора для членов команды, чтобы обеспечить дополнительный структурированный уровень согласованности. Например, в список желательно внести читаемость, безопасность и возможность повторного использования.

Что смотреть при код-ревью

Рассмотрим пункты, на которые стоит обратить внимание при Code Review.

• Качество дизайна кода в системе
• Функциональность в поставленной задаче
• Сложность и возможность упрощения
• Покрытие новых функциональных тестов
• Четкость имен для переменных, классов, методов
• Понятность и полезность комментариев
• Соответствие принятым стайл-гайдам
• Обновление документации (CHANGELOG, например).

Рекомендации для middle разработчиков

Идеального кода не существует. Есть только код, который становится лучше. Результат работы ревьюера — принятие задачи или возврат на доработку.

Ошибки, которых следует избегать

Во время хорошего ревью рекомендуется придерживаться стандартов проверки и избегать ошибок:

• Стремиться исправить все недочеты, а не повысить уровень качества
• Увлекаться комментариями и оставлять фидбек по всем повторяющимся примерам
• Стремиться делать код идеальным, а не соответствующим потребностям проекта
• Затрагивать код, выходящий за рамки задачи
• Спорить о названиях переменных
• Использовать неконструктивную критику вместо аргументов и полезных советов по улучшению
• Зацикливаться на недочетах и не учитывать интересные решения.

Советы по улучшению навыков код-ревью

CR способствует обмену знаниями между программистами разного уровня. Участие в одном процессе открывает возможности для непрерывного обучения и профессионального развития.

Рецензенты получают представление о различных решениях по кодированию. Программисты — конструктивный фидбек и обучение на основе коллективных знаний команды.

Рекомендации для senior разработчиков

Code review осуществляет не тот, кто написал, а тот, кто находится выше. Взгляд со стороны нужен не только джунам. Мидлов обычно проверяют сеньоры, сеньоров — другой сеньор или ведущий программист.

Как делать качественное ревью кода

Правила качественного CR:

• Проводить анализ сразу после выдвижения нового code
• Следовать стандартным практикам кодирования
• Сопровождать обзор тестами
• Быть вежливым, обсуждать код, а не разработчика
• Стремиться к сокращению раундов ревью
• Объяснять, почему требуется внести исправления
• Использовать возможности, чтобы дать точку роста специалисту
• Выдавать таски в зависимости от срочности рабочих задач
• Использовать для ускорения автоматизацию.

Руководство и помощь команде

Улучшить обмен знаниями и снизить накал после CR помогут локальные митапы, где команда в спокойной атмосфере обсуждает фейлы в коде.

В результате таких «программистских стендапов» в команде формируется лояльное отношение к недочетам.

Как код-ревью повышает качество разработки

Code review повышает качество разработки через:

• Обмен знаний, перекрестное сотрудничество и взаимодействие разработчиков
• Навык быстрого выявления и устранения ошибок, что снижает стоимость проекта
• Обзор кода, который поддерживает единый стиль, помогает программистам работать вместе вдолгую, экономит время
• Сплоченность команды, что повышает креативность, эффективность, уровень навыков в команде

Кейсы из практики

Еще в 1988 году компания Hewlett Packard (HP) поставила цель повысить в 10 раз качество кода после проверки своих процессов разработки ПО. Для достижения цели использовали несколько подходов и пришли к выводу, что включение CR в цикл разработки сэкономило больше денег, чем устранение ошибок после обнаружения их пользователями.

Многие программисты на данный момент не видят полноценной замены CR. Иногда в работе совмещают практики design review и парного программирования при выявлении сложного бага. Но эти варианты используют лишь в 10% случаев.

За счет CR быстрее происходит адаптация нового человека в команде, а в design review велика вероятность упустить что-то важное. В парном программировании есть вероятность потерять эффективность.