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

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

Перевод статьи «How to properly give a code review».

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

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

Основы: что такое ревью кода?

Согласно Википедии, ревью кода это:

«Деятельность, направленная на проверку качества программного обеспечения. В ходе ревью кода один или несколько человек проверяют программу, главным образом, просматривая и читая части исходного кода. Делается это после или в ходе реализации. По крайней мере один из этих людей должен не быть автором этого кода».

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

Предполагаю, что ничего нового для вас я пока не сказал. Но есть некоторые не столь однозначные моменты.

  • Когда стоит начинать ревью кода?
  • Как определить, хорошо проведено ревью или нет?
  • Долго ли длится ревью?

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

Ключевое значение имеет подготовка

Ключевое значение имеет подготовка

Прежде чем перейти к просмотру кода как таковому, задайте себе пару вопросов:

  • Знаете ли вы, над чем работает ваш коллега?
  • Знакомы ли вы с участком кода, с которым он работает?

Если на какой-то из этих вопросов вы ответили отрицательно, нужно сделать «домашнее задание». Это поможет вам подойти к ревью кода как можно лучше подготовленным.

Один из способов «наведения мостов» – просмотр тикетов/проблем, связанных с этим функционалом. Там можно найти достаточно информации, чтобы получить представление о масштабах работы и резонах, которые лежат в основе задачи. Кроме того, если ваши настройки рабочего окружения это позволяют, можно просмотреть и комментарии к тикету. Вам нужно узнать, вносились ли в тикет какие-то изменения, не соответствующие его изначальному назначению.

Если ничто другое не помогает, прежде чем приступить к просмотру кода, попросите коллегу пояснить, над чем он работает и почему.

Даже если я знаю, в чем заключается задача, я всегда стараюсь попросить разработчика описать ее своими словами. Таким образом я минимизирую риск остаться в неведении относительно каких-то подробностей задачи. Автор кода, когда ему приходится рассказать о сделанном, может и сам лучше все это понять.

Сначала слушайте, а спрашивайте потом
Photo by kyle smith on Unsplash

Сначала слушайте, а затем спрашивайте

Каждый разговор это улица с двусторонним движением: когда одна сторона говорит, другая слушает. Эта логика вполне применима к ревью кода. Старайтесь не перебивать другого разработчика и не прерывать поток, созревший в его голове. Запоминайте (или записывайте) то, что кажется вам важным, чтобы спросить об этом потом, когда настанет ваш черед говорить.

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

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

Я знаю, что многие из вас задаются вопросом: «Но как же я могу задавать вопросы, если я менее/более опытен, чем другой разработчик? Не будет ли это грубостью?».

Ответ: НЕТ.

Без вопросов нельзя ничему научиться. Смысл ревью кода не только в том чтобы поставить штамп «Одобрено» на то, что сделал другой разработчик. Вы должны проследить за логикой кода, но также несете частичную ответственность за его структуру в целом.

Смысл ревью кода в совершенствовании
Photo by Thao Le Hoang on Unsplash

Проявляйте эмпатию, но будьте честны

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

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

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

Что стоит иметь в виду

Три разобранные выше аспекта ревью кода имеют большое значение, но есть и другие вещи, на которые стоит обратить внимание:

  • Если это будет «в тему», спросите, добавлялись ли модульные тесты. Если да, то пройдитесь по ним.
  • Документация это часть ревью кода. Если ее нет, обсудите возможность ее добавления.
  • До начала ревью спросите у автора кода, сколько, по его мнению, это займет времени (это поможет вам спланировать свой день).
  • Если после ревью кода вносится много изменений, сразу назначьте новое ревью, чтобы следующая итерация не прошла незамеченной.
  • Будьте вежливы и старайтесь хвалить то, что сделал другой разработчик.

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

[customscript]techrocks_custom_after_post_html[/customscript]

[customscript]techrocks_custom_script[/customscript]

Оставьте комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Прокрутить вверх