Как давать и получать более качественные обзоры кода

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

Проверка и отладка

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

Да, я знаю, получать критическую обратную связь может быть сложно, но это единственный способ стать лучше. Кодирование, каким бы одиноким и антиобщественным оно ни было, как его иногда представляют в СМИ, представляет собой совместную командную работу. Признавая это и зная, что проверка кода является неотъемлемой частью опыта программирования, вы, вероятно, задаетесь вопросом, есть ли способы сделать проверку кода менее отстойной для вас и вашей команды разработчиков. Хорошая новость: есть! И именно эти методы получения и предоставления более качественных обзоров кода, которые я изучил за последние несколько лет, которыми я делюсь сегодня.

Получение лучших обзоров кода

1. Контекстуализируйте проблему, которую вы решаете

Моя команда отслеживает большую часть проектной работы через задачи GitHub или JIRA, поэтому, когда мы открываем запросы на вытягивание, мы обнаружили, что ссылка на задачу GitHub или заявку JIRA из тела PR чрезвычайно полезна для объяснения проблемы и предлагаемого решения. Написание краткого резюме или списка изменений, компромиссов и оставшихся задач; пометка пул-реквестов метками; и включение скриншотов или GIF-файлов функциональности для изменений внешнего интерфейса также очень полезно.

Решение проблем и контекст

2. Проверьте свой собственный код, прежде чем официально выставить его на проверку.

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

3. Аннотируйте места, в которых вы особенно не уверены или хотите получить обратную связь

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

4. Отмечайте нужных людей.

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

Общение и проверка кода

5. Сделайте вдох и усвойте отзывы

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


Нужен кто-то, чтобы просмотреть ваш код? Codementor только что запустил свой сервис проверки кода 📝. Узнайте больше о том, как это работает!


Предоставление лучших обзоров кода

1. Задавайте вопросы.

На писательском семинаре, который я посещал, я научился формулировать большую часть своих отзывов как вопросы или размышления. Вместо того, чтобы говорить: «Эй, этот класс — мусор», я пишу такие вещи, как «Вы изучили идею X?», «Каковы ваши намерения с этим подходом?» или «Интересно, перенос этой строки в другой класс сделает функциональность более понятной?»

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

Задавайте вопросы во время обзора

2. Сформулируйте проблемы (если они есть) и предложите альтернативы.

Может возникнуть соблазн отсканировать какой-нибудь код, не прошедший «тест на косоглазие», и написать комментарий вроде «Уф. Это одна дерьмовая куча спагетти-кода» или «Я не могу точно сказать, что не так, но это просто плохо». Я бы посоветовал вам не делать этого. (Я часто делаю последнее, но я работаю над этим.)

Вместо этого постарайтесь очень четко сформулировать свою критику. Можно ли что-то реорганизовать, чтобы сделать его чище или читабельнее? Есть ли фундаментальное непонимание домена? Есть ли что-то, что писатель только что упустил? После того, как вы сформулируете свою критику, также будет здорово предложить несколько альтернатив. Ссылка на документацию или строки кода в кодовой базе. Вы даже можете написать фрагмент, чтобы продемонстрировать, что вы имеете в виду.

3. Постарайтесь понять контекст и предлагаемое решение.

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

4. Подчеркивайте победы.

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

Будьте позитивны и полезны в своем код-ревью

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

Этот пост изначально был опубликован на ХакерПолдень.

Дальнейшее чтение: Масштабирование коллективного владения кодом с помощью Code Reviews в LinkedIn

Похожие записи

Добавить комментарий

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