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

Ревьюирование(инспекция) программного кода

Инспекция кода (Code review) – систематический и периодический анализ программного кода, направленный на поиск необнаруженных на ранних стадиях разработки программного продукта ошибок, а также, на выявление некачественных архитектурных решений и критических мест в программе.

Задачи и цели проведения формальных инспекций

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

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

Такие экспертные исследования называют инспекциями или просмотрами. Существует два типа инспекций — неформальные и формальные.

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

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

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

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

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

Этапы формальной инспекции и роли ее участников

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

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

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

Инициализация

Руководитель проекта или его заместитель запрашивает из базы, хранящей все данные проекта (например, из системы конфигурационного управления), список объектов, готовых к инспекции, выбирает объект инспекции, затем назначает участников формальной инспекции: автора, ведущего и одного или нескольких инспекторов.

Инициализация (продолжение)

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

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

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

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

Инициализация (продолжение)

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

Планирование

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

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

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

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

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

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

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

Время на прочтение
4 мин

Количество просмотров 30K

Что такое Code Review

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

Зачем нужен 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

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

Примеры инструментов:

• 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 style решения, неверно подобранный паттерн проектирования.

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

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

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

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

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

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

Перед стартом

Раунды

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Читайте также:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что такое Code Review

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

Зачем нужен 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

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

Примеры инструментов:

• 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 подразумевает не только поиск нестыковок, но и рекомендации по их устранению, совещание по этапам дальнейших действий.

Критерии хорошего кода

Разработчики, создающие программу, всегда понимают, как должен быть написан хороший код. Каждый специалист, работающий над новым сайтом или приложением, начинает процесс с создания качественной основы. Что подразумевается под качественным кодом? Главное – это простота и гибкость. Создать простой код сложно, это не означает упростить и сократить. Простой код – это максимальная ясность в процессе работы. Для определения качества исходного кодирования, существует несколько точек, по которым нужно ориентироваться:

• Простота восприятия кода. Хороший код не должен содержать множество запутанных конструкций. Специалист должен понять принцип кодирования без дополнительных пояснений и документов.
• Гибкость кода. Простой, но грамотно продуманный код, позволяет производить коррекцию и внесение изменений без потери качества. В случае хорошего исходного кода, в дальнейшем есть возможность изменения конфигурации.
• Возможность дополнения. Код должен позволять вносить новый функционал без опасения нарушения основных алгоритмов.
• Легкость эксплуатации. При возникновении каких-либо неполадок должна быть возможность быстрого решения.
• Доступность. Хороший код подразумевает, что при необходимости, его можно передать для дальнейшей работы другому специалисту. И новый разработчик сможет без труда разобраться в программе, внести изменения и добавить новые пункты.

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

Повышение качества кода

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

Как происходит процесс оценки качества

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

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

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

Преимущества и недостатки процесса проверки кода

Проверка в технике Code Review выявляет недочеты в разработанном коде на ранних этапах. Такая тактика дает возможность избежать внеплановых ситуаций и затрат в будущем. Можно определить еще несколько плюсов такого подхода:

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

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

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

• Главная
• Блог
• Код-ревью: полное руководство о том, как проводить код-ревью

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

07, сент. 2022

7 мин

Содержание

Начните бесплатно

Хотите попробовать сами?

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

Воплотите свои идеи в жизнь