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

Code Review (Код–ревью) – процесс проверки и анализа кода перед релизом.

Обычно он преследует две цели:

Выявление:

• Ошибок.

• Пропусков.

• Стилистических ошибок.

• Уязвимостей.

• Комментариев к коду.

Улучшение:

• Читаемости кода.

• Архитектуры.

• Коммуникации в команде.

• Адекватности релиза.

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

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

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

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

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

• Код становится чище и понятнее для прочтения. Что позволяет его улучшать в будущем и оптимизировать процесс разработки.

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

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

К минусам код–ревью можно отнести:

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

Проводить Code Review требуется не всегда.

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

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

Если речь идет о проведении код–ревью на постоянной основе, то причинами для отказа от процедуры можно назвать следующие:

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

• В процессе работы над проектом применяются иные практики, например, парное программирование.

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

• Компания прибегала к данному методу проверки кода, но он не доказал своей эффективности. Например, не были выявлены ошибки в коде или какие–либо уязвимости, что в итоге сказалось на качестве продукта.

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

1 этап: Создание Merge Request.

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

2 этап: Назначение ответственных лиц.

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

3 этап: Раунды.

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

Каждый раунд тоже делится на короткие этапы:

• Оценка размеров MR.

• Осуществление глобальных правок.

• Внесение менее важных правок.

• Работа над правками, которые требуют особого внимания.

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

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

Существуют несколько критериев для того, чтобы понять, что решение готово к релизу.

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

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

• Созданное решение не выходит за рамки скоупа задачи.

• Код прошел проверку линерами. Если мы имеем в виду язык Python, то для него применяется, например, black, isort или flake8.

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

• Нет потребности в оверинжиниринге, то есть в запасном коде, который решает предполагаемые проблемы.

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

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

Автоматизация.

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

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

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

Важно проверять каждого участника разработки.

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

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

Проверка каждой задачи.

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

В рамках одного Code Review не должен проверяться слишком большой объем кода.

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

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

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

Существуют некоторые аспекты, требующие особого внимания во время Code Review.

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

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

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

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

Code Review тоже не обходится без использования различных инструментов. Их выбор зависит от множества факторов:

Возможности компании.

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

Цели.

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

Языки программирования.

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

Уровень компетенций специалистов.

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

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

GitHub.

Дает возможность проверить код с помощью pull–запросов. То есть проверяющий получает доступ к репозиторию, привязать себя к запросам и завершать ревью. Разработчик, принявший pull request, имеет возможность запрашивать ревью у администратора.

Также GitHub позволяет вести обсуждение в общем pull–запросе, проводить анализ diff, оставлять строчные комментарии и следить за изменениями. Простые конфликты в Git можно разрешить через веб–интерфейс.

Upsource.

Специализированный инструмент для проведения код–ревью. Дает возможность осуществлять проверку на мобильных устройствах. Обладает всеми необходимыми функциями для автоматизации процесса.

С ним возможна аналитика проекта и управление данными. Он поможет обеспечить безопасность и продвинутое управление пользователями.

Upsource может интегрироваться с системами управления проектами, а также с системами GitHub и GitLab. Имеет совместимость со множеством языков, что позволяет ему качественно проводить анализ.

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

Кроме специализированных инструментов, которые позволяют проверять код, в работе разработчикам и проверяющим могут понадобиться средства коммуникации и управления задачами. Среди них различного рода электронные доски типа Trello, системы Jira и Microsoft Teams.

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

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