что такое ревью в айти

Что такое код-ревью и кто им занимается?

Эффективный способ заботиться о качестве кода

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

Задачи код-ревьюера

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

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

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

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

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

Этапы работы и инструменты

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

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

«На этих этапах не нужно никаких специальных инструментов. Только экспертные навыки и знание задачи. Код-ревьюеру понадобятся некоторые инструменты среды лишь для того, чтобы посмотреть, как работает код, и обнаружить грубые ошибки», — говорит Андрей Строгов.

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

«Наша задача в том, чтобы разработчик понял, в чём заключается комментарий и почему важно исправить код в соответствии с ним. Для этого недостаточно сильных технических знаний, нужны хорошие soft skills. Если ревьюер дал полезный комментарий, а разработчик почему-то не захотел исправлять — это будет выглядеть глупо», — говорит Андрей Строгов.

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

«Не стоит оставлять комментарии в духе “бред какой-то” или “тут ты не подумал”. Нужно формулировать проблему корректно. Субъективное мнение тоже не помогает улучшить код. Лучше найти что-то точнее, чем “это непонятный код”», — говорит Андрей Строгов.

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

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

Знания и навыки

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

«Нужно отучить себя от того, что ты обязательно должен написать комментарии после ревью. Если с кодом всё в порядке, он может вернуться к автору без замечаний, которые оставляют ради самих замечаний», — говорит Андрей Сторогов.

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

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

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

Источник

Еще одна статья о code review

Что такое code review

Что можно инспектировать

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

Как проводить review

Вообще, ревью кода должен проводиться в совокупности с другими гибкими инженерными практиками: парное программирование, TDD, CI. В этом случае достигается максимальная эффективность ревью. Если используется гибкая методология разработки, то этап code review можно внести в Definition of Done фичи.

Из чего состоит review

Также очень важно определиться, за кем будет последнее слово в принятии финального решения в случае возникновения спора. Обычно, приоритет отдается тому кто будет реализовывать код (как в scrum при проведении planning poker), либо специальному человеку, который отвечает за этот код (как в google — code owner).

Как проводить design review

Design review можно проводить за столом, в кругу коллег, у маркерной доски, в корпоративной wiki. На design review тот, кто будет писать код, расскажет о выбранной стратегии (примерный алгоритм, требуемые инструменты, библиотеки) решения поставленной задачи. Вся прелесть этого этапа заключается в том, что ошибка проектирования будет стоить 1-2 часа времени (и будет устранена сразу на review).

Как проводить code review

Можно проводить code review разными способами — дистанционно, когда каждый разработчик сидит за своим рабочим местом, и совместно — сидя перед монитором одного из коллег, либо в специально выделенным для этого месте, например meeting room. В принципе существует много способов (можно даже распечатать исходный код и вносить изменения на бумаге).

Pre-commit review

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

Post-commit review

Данный вид review проводится после внесения изменений в VCS. При этом можно коммитить как в основную ветвь, так и во временную ветку (а в основную ветку вливать уже проверенные изменения).

Тематические review

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

Результаты review

Сложности при проведении review (субъективное мнение)

Основная сложность, с которой мы столкнулись, когда внедряли review в первый раз: это невозможность контроля изменений по результатам review. Отчасти это связано с тем, что данная практика применялась без других практик — CI (это еще раз доказывает тот факт, что все инженерные практики должны применяться вместе).

Утилиты для review

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

Ссылки

Пожелания, дополнения, критика приветствуется

Источник

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

Что такое Code Review

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

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

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

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

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

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

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

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

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

Рекомендации по организации Code Review

Code Review может быть организован по-разному в разных командах. Главное, чтобы команда заранее обговорила и утвердила свои внутренние правила, которых она хочет придерживаться и с которыми все согласны, чтобы каждый раз не возвращаться к этому вопросу.

Избегать рутинных проверок Code Style людьми: автоматизировать такие проверки. Можно использовать для этого любые подходящие вам инструменты для автоматической проверки code style используемого вами языка программирования. Например, для PHP это может быть PHP Coding Standards Fixer https://cs.symfony.com/ Не нужно тратить время разработчиков на то, что можно автоматизировать. Также обратная связь по поводу code style от людей воспринимается как “придирки” и может создать не очень позитивную атмосферу в команде.

Code Review должен проводиться для каждого участника команды, вне зависимости от уровня. Не должно быть такого, что ревьювят только задачи, которые сделали Junior разработчики, тем временем Senior разработчики не отдают свои задачи на ревью. Необходимо, чтобы ревью проводилось для задач всех разработчиков.

Code Review является частью процесса и необходим каждой задаче. Это правило избавляет от лишних споров и холиваров насчет небольших задач. Ревью проходят все задачи без исключений.

Code Review проводится перед релизом задачи и перед передачей ее в тестирование. Это помогает избегать повторного тестирования, а также соблазна оставить все как есть, ведь “и так работает”. К задачам, которые уже на бою, никто не захочет повторно возвращаться.

Избегать слишком больших объемов кода в одном Code Review. Если задача большая, то необходимо отправлять ее на ревью частями. Есть рекомендуемое число 200-400 строк в одном ревью. При увеличении количества строк, эффективность и продуктивность ревью резко падает.

Если нет возможности внести какие-то правки после ревью, то необходимо завести задачу в трекере задач, а в коде оставить ToDo с ее номером

Чего следует избегать:

Если Code Review непостоянная часть процесса разработки, то это приведет к нестабильному ревью, его будут откладывать и команда не получит всех плюсов этого процесса.

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

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

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

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

Проверить, что реализация соответствует всем указанным в исходной задаче условиям

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

Протестировать задачу локально и убедиться, что она работает, как нужно

Подготовить описание для ревьювера, если какой-то информации в задаче не хватает

Проверить, нужны ли какие-то комментарии в самом коде и добавить при необходимости

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

Ознакомиться и понять цель и суть задачи

Проверить общую архитектуру и подход к решению

Проверить мелкие детали (имена функций и переменных и т.д.)

Проверить наличие тестов и документации по необходимости

Список ToDo: изменения, которые необходимо внести в код после ревью

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

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

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

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

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

Источник

Перфоманс ревью и обратная связь в IT

Некоторые компании до сих пор считают, что перфоманс ревью — бесполезная трата времени, особенно в IT компаниях. Хотя обратная связь, которую можно наладить с его помощью, частично закрывает боль «И снова он сбежал». Если мы посмотрим на мир за пределами нашей страны, то увидим, что довольно большой процент компаний использует мотивацию и ревью, как способ сделать компанию лучше. Среди таких можно перечислить: Google с ее системой OKR, Adobe с ее постоянной обратной связью, General Electric с собственным приложением для повышения производительности и другие компании.

Так что же это за метод такой?

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

Кому он нужен?

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

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

Характеристики хорошего перфоманс ревью

Как выстраивается процесс?

Несколько советов напоследок

СОВЕТ № 1: помните, что конструктивная обратная связь используется, чтобы помочь сотруднику определить, что пошло не так, и как он может лучше справиться с ситуацией в будущем. Изложите свои выводы и предложенный процесс в письменной форме, чтобы у сотрудника были четкая инструкция по предлагаемому решению. Таким образом, не возникнет недопонимания.

СОВЕТ № 2: важно адаптировать свое общение к стилю работы сотрудника и его уникальным мотивам. Сотрудник, который непреклонен в карьерном росте, может лучше отреагировать на конструктивную обратную связь. Если объяснить, как его действия повлияют на его будущую роль в компании. Знание того, что движет сотрудником, поможет вам связать конструктивную обратную связь с их реальными амбициями в вашей компании, что еще больше повысит их вовлеченность и производительность.

СОВЕТ № 3. Если сотрудник плохо работает, задавайте вопросы. Не думайте, что вы знаете причину, и не делайте поспешных выводов о том, что он ленив, она тупица, он немотивирован или она некомпетентна. Используйте свои разговоры об оценке эффективности как возможность выяснить, каковы возможные причины неспособности сотрудника соответствовать стандартам и ожиданиям. Подсказка: когда сотрудник не работает должным образом, основной причиной часто является неспособность начальника обучать!

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

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

Источник

Код ревью, как внедрить и не испытывать боль

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

20% времени мы пишем новый код.

80% времени поддерживаем старый. Поддержка в себя включает фиксы багов, обновление кодовой базы (переезд на новые библиотеки например).

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

Способы иметь хорошо поддерживаемый код:

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

Что же такое код ревью?

Что нам даёт код ревью:
​ Проверку кода по многим критериям.
Автор не всегда видит неочевидные места в его коде (по разным причинам).
В результате написания и переписывания может быть потеряна композиция.
Автор, находясь в контексте задачи может недостаточно оставить комментариев.
Эти и многие другие проблемы может решить код ревью.

​ Шаринг знаний о проекте.Не только автор знает, что там пишется в другом проекте или части проекта, а все.

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

​ Сотрудники быстрее онбордятся. Новые сотрудники, проводя код ревью, быстрее узнают и понимают традиции команды, а проходя его, имеют возможность исправить ошибки, узнать больше о продукте и меньше испытывать стресс.

Способов поддерживать код «качественным» есть много, но все их нужно правильно готовить. Нужно уметь писать тесты, нужно уметь писать документацию и нужно правильно организовать код ревью.

Советы по организации процесса

Условные обозначения:
— Как делать не нужно
+ Как делать нужно

​- Ревьюить только джунов и новых коллег
​+ Проводить ревью для всех и всеми

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

-​ Обсуждать на код ревью стиль
+​ Настроить у себя на проекте инструменты, которые автоматически будут исправлять стиль перед коммитом

В JS это eslint и prettier. Не тратьте время своё и коллег на споры о вкусах. Договоритесь заранее и пропишите правила. В случае разногласий голосуйте.

Не обсуждайте стиль на ревью

-​ Ревьюер запускает руками билд или проверяет код на баги.
​+ Автор сам несет ответственность за поставленный код.

Автор тщательно проверил свой код на работоспособность и залил в удаленный git репозиторий

На сервере CI/CD проверяет тесты, сборку, работоспособность в целом.

Проверка со стороны ревьюера.

-​ Ревьюер не читает код
+​ Обращать внимание на композицию, магические переменные, оптимизацию (там где это имеет смысл)

Обращайте внимание на код ревью.

​- Агрессия, негатив, «токсичное» поведение в комментах
+​ Старайтесь отмечать не только негативные стороны, но и хвалить за позитивные.

Агрессия, негатив и токсичное поведение в принципе стоит избегать во всех областях жизни. Грубое поведение во время код ревью может привести к:

Стрессу и страху совершить ошибку

Примеры плохих комментов:

Примеры хороших комментов:

«Давай попробуем сделать …» «Может попробуем вынести…»

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

Чаще хвалите код в ревью

-​ Все комментарии обязательны к исправлению
+​ Помечать необязательные комментарии

​ Пытаться объяснить алгоритмы на словах
​ Написать пример псевдокода

Особенно актуально, если автор не совсем понимает что от него хочет ревьюер. Не нужно полностью писать реализацию. Напишите небольшой пример псевдокода. Gitlab, github и bitbucket позволяют вставлять в комментарии разметку markdown. Ваш код будет хорошо отформатирован и более понятен, чем длинная цепочка комментов.

-​ Оставлять больше 50 комментариев
+​ Оставлять до 50 комментариев

Если комментариев накапливается очень много, то у вас:

Или не настроены линтеры, и вы не определились со стилем, поэтому комменты о вкусовщине

Или переделать в коде нужно многое

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

Если код будет переписан полностью, отследить изменение по комментариям практически невозможно и они не имеют смысла. Авторы тоже должны это понимать и следить, чтобы всем было комфортно.

-​ Отправлять огромные фрагменты кода на ревью
+​ Дробить большие участки кода на несколько реквестов и вливать постепенно

Задачи бывают разными по объему. Может быть задача исправить 1 строчку кода, а может быть задача отрефакторить весь проект. Во втором случае не отправляйте реквест в котором исправлены 500 файлов и 4000 изменений. Никто в здравом уме не сможет это нормально проверить, и желания такое проверять вы тоже не найдете.

Сделайте ветку feature/epic-name

Изменения делайте в ветке feature/epic-name-implement

Pull реквесты делайте в ветку feature/epic-name. Порционно.

В конце реализации фичи подлейте feature/epic-name в мастер. Да, в этом случае пулл реквест тоже будет огромный, но всё уже будет заранее проверено

Другой вариант как этого избежать: feature flags. Вы вливаете изменения на прод, но не даете им пользоваться. Нормально это реализовано мало у кого. Поэтому с этим подходом нужно быть осторожнее.

Уважайте тех, кто будет проверять ваш PR

-​ Pull Request висит без ревью трое суток
+​ Выработать расписание

Среди аргументов против код ревью вы услышите, что с ним у вас увеличивается время «доставки» фич. Чтобы этого не происходило, выработайте у ревьюеров расписание. Например, новые реквесты проверять до работы и перед уходом домой, а исправленные в перерывах в течении дня (например пока проект собирается или тесты гоняются).

В заключении

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

Если в вашей команде нет код ревью, то самое время его внедрить ​.

Ссылки и благодарности

По теме рекомендую почитать:Статья How to Do Code Reviews Like a Human
Спасибо лису и kirjs из @learnInPublic за ревью статьи про ревью.

Источник