Обложка: Код-ревью — как сделать правильно

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

Дмитрий Хитрин
Дмитрий Хитрин

разработчик Яндекс.Дзена

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

Принципы хорошего код-ревью

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

Чтобы сделать код-ревью полезным, всем участникам процесса нужно соблюдать несколько правил. Я расскажу о 7 принципах хорошего код-ревью.

Уважайте друг друга

Даже если вам кажется, что фраза «Я сегодня вышел на улицу, наступил в мокрый снег, и ощущения от этого были гораздо лучше, чем от вашего кода» очень смешная, и человек на неё не обидится, не стоит её использовать. Это можно сказать иначе: «Я думаю, в этом месте можно было бы сделать вот так». Будьте доброжелательны и помните, что вы оцениваете не человека, а его код. Это может казаться мелочью, но это база, из которой складывается здоровая атмосфера в команде и эффективная работа.

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

Будьте объективны

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

Если вы столкнулись с тем, что человек написал код не так, как это принято на проекте, отправьте ему ссылку на код коллеги. И помните: аргументацию стоит писать уважительно — без подтекста «Как ты можешь этого не знать?»

Полезные фразы «Обычно такие вещи мы делаем немного иначе [ссылка на документацию], «вот ссылка на проект наших коллег — они очень здорово решили похожую задачу, думаю, мы можем перенять их опыт».

Пример из реального код-ревью:

import React, {FC, memo} from "react";
import {Link} from "react-router-dom";

export const Footer: FC = memo(() => {
    return (
        <footer className="footer container">
            <Link to="/" className="footer__logo-link">
                <img
                    className="footer__logo"
                    src="img/logo.svg"
                    alt="6 cities logo"
                    width="64"
                    height="33"
                />
            </Link>
        </footer>
    );
});

В комментарии я даю ссылку на документ и поясняю, в чём ошибка

Не давайте готовое решение

Этот принцип особенно важен в учебных проектах. Задача ревьюера-наставника — подтолкнуть человека в правильную сторону, подсказать, как ещё можно подступиться к задаче, какие инструменты можно использовать.

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

Больше общайтесь с командой

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

Полезные фразы «Если хочешь, можем созвониться, пообщаться голосом. Я буду рад подробно всё объяснить».

Учитесь в процессе код-ревью

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

Несите ответственность за код

Правильное отношение к код-ревью — считать, что вы несёте такую же ответственность за будущую корректную работу кода, как и его автор. Ведь от ваших комментариев зависит, насколько качественно человек выполнит свою работу.

Внимательно относитесь к новичкам

Если вам предстоит разобрать на код-ревью работу новичка, значит, нужно подойти к этому ещё ответственнее, чем обычно. От первой полученной обратной связи зависит, как человек будет работать в дальнейшем, а возможно, останется ли он вообще с вами. Чем ответственнее вы и ваши коллеги относятся к код-ревью, тем быстрее растут новички как профессионалы.

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

В дополнение к базовым принципам хорошего код-ревью, в Яндексе мы придерживаемся ещё трёх правил.

Проверяем код на уровне логики и решений

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

Не жалеем времени на код-ревью

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

Не заливаем код, который не прошёл ревью

Во многих командах Яндекса эта вещь ограничена программно — новый код нельзя влить, пока он не получит определённое количество аппрувов (одобрений) от коллег. Это правило позволяет использовать в работе только качественный код.

Чек-лист хорошего код-ревью

Чек-лист поможет сделать ревью полезным, а коммуникацию — эффективной.

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

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

Хинт для программистов: если зарегистрируетесь на соревнования Huawei Cup, то бесплатно получите доступ к онлайн-школе для участников. Можно прокачаться по разным навыкам и выиграть призы в самом соревновании.

Перейти к регистрации