Ревю в программировании что это

Code Review – зачем и как использовать в команде?

Code Review — это процесс проверки и анализа кода задачи разработчиком перед ее релизом. CR (Code Review) выполняется не тем человеком, который делал задачу, а другими членами команды. Результатом CR является обратная связь по выполненной задаче: необходимость внести правки, либо готовность задачи к последующему тестированию и релизу.

Зачем нужен Code Review

Code Review может являться частью процесса выполнения задачи (частью workflow). Может показаться, что ревьювить должен только тимлид или старший разработчик, но хорошей практикой является если в процессе ревью задач участвуют все разработчики. Таким образом можно не только распределить нагрузку от ревью, но и составить у команды более широкое представление о выполняемых задачах. Также это помогает делиться best practices внутри команды.

Положительные эффекты в команде от Code Review:

понижает bus factor: больше людей в команде в курсе выполняемой задачи, в случае необходимости внесения изменений в задачу как минимум два человека смогут это сделать. Задача больше не завязана на одного разработчика.
помогает найти и выявить баги и недоработки на этапе разработки задачи: так как задача сразу проверяется как минимум двумя разработчиками, это повышает вероятность нахождения упущенных кейсов, которые без код ревью могли бы попасть на бой.
повышается читаемость и качество кода и как следствие — его поддержка в будущем: код понятен не только одному человеку, а нескольким участниками команды, это упрощает и ускоряет разработку в будущем.
обучаемость сотрудников: разные реализации и подходы к решению задач могут заимствоваться участниками команды друг у друга во время код ревью
развитие и поддержание здоровой культуры в команде: участники команды учатся друг у друга и учатся давать качественную обратную связь, повышается взаимодействие внутри команды.

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

На что обращать внимание во время Code Review

Чеклист для разработчика перед отправкой на ревью:

Проверить, что реализация соответствует всем указанным в исходной задаче условиям
Проверить соответствие Code Style и другим принятым в команде гайдлайнам, например, наличию unit-тестов и документации
Протестировать задачу локально и убедиться, что она работает, как нужно
Подготовить описание для ревьювера, если какой-то информации в задаче не хватает
Проверить, нужны ли какие-то комментарии в самом коде и добавить при необходимости

Чеклист для ревьювера:

Ознакомиться и понять цель и суть задачи
Проверить общую архитектуру и подход к решению
Проверить реализацию
Проверить мелкие детали (имена функций и переменных и т.д.)
Проверить наличие тестов и документации по необходимости

Список ToDo: изменения, которые необходимо внести в код после ревью
Вопросы: обозначить свои вопросы по частям кода, которые непонятны после ревью
Предложения по улучшению: внести свои предложения и пожелания по коду задачи и/или связанных задач. Например, договориться о создании задачи по обновлению старого метода в других участках кода на новый и завести на это ToDo и задачу в трекере задач и поставить ее в тех. долг команды.

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

Инструменты для Code Review

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

GitHub Code Review https://github.com/features/code-review/
Upsource https://www.jetbrains.com/ru-ru/upsource/
Crucible https://www.atlassian.com/ru/software/crucible
Collaborator https://smartbear.com/product/collaborator/overview/
Beanstalk https://beanstalkapp.com/

код ревью
code review
процессы разработки

В тысячный раз о code review

Потому что я вбила здесь в поиске «code review» и обнаружила 50 страниц по 20 результатов на каждой.

Штуки три с высоким рейтингом прочитала. Но всё по понятным причинам не осилила.

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

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

Для тех, кто не в курсе, code review – это процесс просмотра кода, сделанного одним разработчиком, другим разработчиком с последующей выдачей комментариев. В идеале, это повышает качество кода.

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

Это цена. Не все команды согласны её платить в погоне за качеством. Мне везло работать в тех, что согласны.

Итак, поехали. Как проводить code review, чтобы извлечь из процесса максимальную пользу?

Вежливо. Даже если вам кажется, что коллега написал это код в пьяном угаре не иначе, нужно выдавать свои комментарии в максимально корректной форме. Все ошибаются. Это не повод их стыдить, высмеивать и прочее. Цель всего — улучшить качество вашего совместного продукта. А блеснуть своим белым пальто можно и в другом месте, если хочется. Пишите комментарии так, как вы бы хотели, чтоб их писали вам.

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

Задавать вопросы в случае недопониманий. Тут всё просто. Нужно стремиться понять чужую мысль на 100%. Как вы знаете, если когда-нибудь читали чужой код, это не всегда бывает просто. Если что-то непонятно – спросите автора, можно по телефону, если так быстрее.

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

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

Использовать чек-лист. Чтобы повысить эффективность себя как ревьюэра, хорошо бы завести список того, на что надо обратить внимание. Мои три общеупотребимые вещи для проверки: дубликации кода; грамотное использование RAII (это ещё что такое? Кто не знает — объясню как-нибудь ещё); грамотное именование сущностей. Остальное специфично для языка и для проекта.

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

Как НЕ НАДО проводить code review?

Юмор за 300. Как мы помним, вежливось очень ценна для грамотного code review. Я понимаю, что бывает присылают на ревью такое, что сложно не взоржать, и что мы все тут дофига юмористы. Но правда, лучше поржите с подружками после работы. Если у вас есть подружки-программистки не из вашей команды, расскажите им эту фееричную шутку – они оценят. Code review достаточно личная штука и шутки над кодом могут быть восприняты как личное оскорбление. Не надо так.

Пытаться делать работу по отлову ошибок. Это не то, на чём нужно концентрироваться. Для отлова ошибок существует тестирование, валидация в конце концов. Оставьте эту работу тестам. А при ревью лучше сконцентрироваться на том хорошо ли код спроектирован. SOLID принципы, идиомы объектно-ориентированного программирования. Вот это всё. На этом концентрируйтесь. Хорошо ли такой код будет расширять и поддерживать в дальнейшем? Эти вопросы должны вас волновать в первую очередь, на мой взгляд.

Проверять соответствие стилю (в смысле coding style/coding guidelines). Не нужно. Все проверки правильного количества пробелов, длинны строк, наличия табов и т.д. оставьте роботам. Т.е. просто введите в ваши процессы автомат по выравниванию стиля. Indent, clang-format и т.д. вам в помощь.

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

Всем хороших code review.

А с меня хватит на сегодня, пожалуй.

Что такое код-ревью

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

Послушать аудиоверсию этой статьи (6 минут):

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

Когда вы пишете новую функцию, она не попадает сразу в проект. Вместо этого ваш код отправляется на код-ревью (code review).

Что делают на код-ревью

Во время код-ревью кто-то из старших товарищей изучает ваш код на предмет:

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

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

Кто проводит

Обычно принято так: код-ревью делают программисты более старшего уровня. Джуниоров проверяют мидлы, мидлов — сеньоры, сеньоров — другие сеньоры или тимлиды. Если компания большая, то могут выделить отдельно несколько человек, которые смотрят код у всех и следят за общим стилем.

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

Как это выглядит

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

Зачем это нужно

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

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

Получите ИТ-профессию

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

Как провести код-ревью: советы по применению

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

Изображение записи

Текст будет полезен разработчикам и лидам, которые еще близко не знакомы с код-ревью или хотят упорядочить свои знания, узнать лайфхаки из практики.

Что такое код-ревью и зачем его проводят?

Код-ревью — это процесс проверки кода, который позволяет:

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

улучшить →

→ читаемость и понятность кода для других разработчиков.

→ архитектурные решения. Например, разбиение на модули, code style решения, неверно подобранный паттерн проектирования.

→ работу в команде. Способствует диалогу между автором кода и ревьюером, дает возможность прокачать навыки и узнать что-то новое.

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

Когда не нужно проводить код-ревью?

Системная практика оценки кода внутри команды — не всегда полезное с точки зрения затраты ресурсов решение. Оно отнимает время и у автора, и у проверяющего, а еще требует глубокого погружения в процессы и сил на коммуникацию.

Причины, чтобы отказаться от код-ревью в конкретном случае:

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

Причины, чтобы отказаться от постоянной практики код-ревью:

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

Как организовать процесс проверки кода?

После выполнения задачи автор кода делает в отдельной ветке push в удаленный репозиторий и создает Merge Request (MR).

Назначается assignee (ответственный за MR) и reviewer (ответственный за проверку).

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

Раунды

Перед стартом ревьюер должен оценить объем MR и определить, сможет ли его проверить на «одном дыхании»‎ — не теряя концентрации. Если объем MR слишком большой, советуем разбить его на части поменьше. Чем объемнее решение, тем ниже эффективность проверки.

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

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

«В первом раунде не стоит акцентировать внимание на мелких недочетах. Скорее всего, автор сам их обнаружит и поправит, и ревьюеру не придется тратить время на поиск незначительных проблем»‎, — отмечает разработчик Selectel Антон Щербак.

После код возвращается автору: он вносит изменения и снова отправляет на проверку. Процесс продолжается до тех пор, пока решение не признают приемлемым — оно одобряется тем, кто проводил ревью, и после assignee выполняет merge.

«Решение не должно быть идеальным — оно должно соответствовать потребностям проекта и выполнять поставленную задачу»‎, — резюмирует Антон Щербак.

Как понять, что решение готово?

→ Оно не имеет явных ошибок.

Ревью может выявить недочеты, которые видны без запуска проекта. Обычно это:

опечатки;
ошибки, возникшие из-за недостаточного погружения в контекст проекта;
необновленный конфигурационный файл.

→ Соответствует стайл-гайдам, принятым в команде.

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

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

→ Не затрагивает код, выходящий за рамки задачи.

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

→ Пропущено через линтеры, используемые в проекте.

Большинство команд в Selectel использует pre-commit — так при каждом коммите код прогоняется через линтеры. Для Python используется black, isort, flake8, pyupgrade и autoflake.

→ Обладает хорошей читаемостью и пояснением неочевидных мест.

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

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

→ Если на проекте пишутся автотесты, решение должно ими покрываться.

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

→ Нет оверинжениринга (кода «на будущее»‎).

Часто код, который решает еще не возникшие проблемы, не пригождается и становится лишним.

Еще Дональд Кнут говорил: преждевременная оптимизация — корень всех проблем в программировании.

Советы по процессу

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

Хорошая практика — восприятие код-ревью как отдельной задачи без переключения на другие. Правда при условии, что у остальных дел невысокий приоритет.

Второй: используйте префикс NIT (сокращение от nitpick) для комментариев, которые даны в качестве рекомендаций. Помните: они не обязательны к исполнению, автор волен сам решать, следовать им или нет.

«Разработчики часто спорят о названиях переменных. Бывает, что эти нововведения никак не влияют на итоговое решение. Поэтому делать пометку в начале — нормальная практика: она говорит разработчику, что решение о внесении в код изменений остается за ним. Эти изменения не обязательны — решение и так хорошее‎»‎, — рассказывает разработчик Selectel Антон Щербак.

Третий: помните о том, что обратная связь должна быть балансной. Ее цель — не обидеть человека, а аргументировано (например, с помощью примеров кода и ссылок на паттерны) подсветить зоны для улучшений.Кроме того, не зацикливайтесь только на ошибках: если видите интересное решение или нестандартный подход, похвалите его. Так лишний раз покажите коллеге, что у вас одна цель, и снимите напряжение.

Так не стоит комментировать → «Ты тут ошибся, поправь по моему примеру. Вот ссылка».

Так лучше → «Мы уже сталкивались с аналогичной ситуацией. Вот как эта проблема решилась тут → ссылка. Можем ли реализовать нечто подобное?»

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

Удобные инструменты для код-ревью

GitLab — используем в Selectel.

По ссылке конкретные гайдлайны, которыми пользуются в GitLab. В них описано, как построена практика код-ревью в компании.

GitHub. Подробнее об инструменте — по ссылке.