6 советов для успешного Code Review

Привет, Хабр! Представляю Вашему вниманию перевод статьи «6 Tips To A Successful Code Review».

Сode review во все времена являлся основополагающей практикой, отвечающей за создание чистого и поддерживаемого кода.

Частенько разработчики пренебрегают и недооценивают code review по причинам, которые кажутся в тот момент объективно правильными.

Давайте сегодня сформулируем 6 советов, чтобы провести качественный и плодотворный code review.

I – Выбери Правильный Момент

Выполнение code review начинается с выбора подходящего момента.

Давайте попробуем описать его характеристики:

• Низкий шанс того, что вас прервут: стоит избегать рабочего времени, в течение которого, исходя из опыта, люди склонны отвлекать от рабочего процесса. Ведь некоторые дни часто имеют более спокойные периоды, и как раз в такие моменты стоит запланировать code review.
• Чистый и ясный ум: не стоит испытывать стресс до начала ревью и в процессе, например, опасаясь грядущей встречи с бизнес-холдером. Так же программист, чей код предстоит проверить, должен быть в спокойном состоянии, что бы между вами не возникло напряжение, способное разрушить процесс обзора кода.
• Разработчик гарантирует, что код готов к проверке: нет смысла тратить время на просмотр того, что еще не готово. Под готовностью подразумевается, что код рабочий, без bad practice, задокументированный и хотя бы покрыт Unit-тестами. Исходя из опыта, если разработчик сам выделяет время на code review, то с большей долей вероятности отдаст на проверку код, за который ему не стыдно.

II – Установите границы

Стоит заранее понимать грядущие масштабы code review.

Рассмотреть одну или несколько функций? Учитывая время, есть ли смысл рассматривать слишком много?

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

Чтобы правильно расставить границы задачи, можно:

• Выполнять поставленные задания обозримого размера. Для этого делите большие задачи на маленькие и атомарные, например, в Jira или даже на классической Scrum доске.
• Правильно расставлять приоритеты проверки кода: если проверки ожидает слишком много задач, не получится просмотреть все. Выбирайте приоритетные.

III – Установите правильную атмосферу

Перед началом code review установите благоприятную атмосферу вокруг себя.

Что для этого потребуется?

• Минимальное количество посторонних звуков: вы будете продуктивнее, если вокруг будет как можно меньше шума. Ведь чем его меньше, тем лучше концентрация.
• Нет зоны «прерывания»: аналогично тому, что было описано в первой части, стоит избегать моментов, когда могут оторвать от процесса. Проще это сделать в отдельной комнате.
• Зона позитивной критики: критиковать чужой труд — сложный процесс. Но еще труднее это делать, когда вокруг много людей. В закрытой комнате можно свободно высказываться, не опасаясь, что вас подслушивают.

IV – Общайтесь, общайтесь и еще раз общайтесь

Проверка кода – это не односторонний процесс.

Успешный code review в высшей степени зависит от способности уважительно и эффективно общаться с коллегой. Ведь не только проверяющий заявляет, что правильно, а что нет.

Code review – это разговор обо всем: масштабе, намерениях, исправлениях и даже разногласиях.

В процессе попытайтесь придерживаться следующих рекомендаций:

• Не только слушайте, а услышьте: мнения и взгляды часто различаются, и каждое разногласие обязано породить конструктивное обсуждение вопроса. Каждая точка зрения нуждается во внимании.
• Нейтральный тон: проверка кода – это не экзамен и не инквизиция.Создайте ощущение, что пришли судить код, а не человека, который его написал.
• Терзают сомнения – уточните: если не уверены в конкретной детали реализации, спросите об этом. Некоторые намерения, которые не очевидны с первого взгляда, часто порождают неправильные интерпретации в дальнейшем.

V – Помните о конечной цели

Code review должен приводить к конечному результату: это может быть конструктивная критика и советы по улучшению или интеграция кода с соответствующими ветвями разработки, которые выбраны в gitflow.

В этом и заключается ответственность рецензента.

Но как рассудить, может ли код быть интегрирован?

Вот некоторые критерии, которые помогут с решением:

• Написанный код решает задачу, описанную в постановке.
• Код правильно покрыт unit-тестами.
• Правильно решены merge-кофликты.
• Нет очевидных признаков запаха кода или плохих практик.

VI — Используйте специальные инструменты

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

На рынке программного обеспечения для проверки кода лидируют три бренда: Smartbear (с Collaborator), Perforce (с Helix Swarm) и Atlassian (с Crucible)

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

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

Попробуйте!

Ваша очередь делиться!

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