Представлены методы и инструменты в Code Review

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

Что такое Code Review?

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

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

Разработка обычно ведется на так называемых функциональных ветках, которые периодически интегрируются в основную ветку. Проверка кода выполняется перед «слиянием», т.е. ЧАС. прежде чем новый или измененный код будет объединен с существующей кодовой базой. Цель состоит в том, чтобы обнаруживать ошибки на ранней стадии и устранять их до того, как код будет запущен в производство.

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

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

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

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

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

Как работает code review?

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

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

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

Давайте рассмотрим отдельные шаги CI-конвейера и место в нем code review в обзоре:

1. Написать код
   1. Написать код в функциональной ветке
   2. Тестовый код в локальной среде
2. Интегрировать код в кодовую базу
   1. Автоматически анализировать и форматировать код в ответвлениях функций
   2. Проводить код-ревью и вносить улучшения
   3. Слить код в основную ветку
   4. Разверните и протестируйте основную ветку на промежуточной площадке
3. Внедрение кода в производство
   1. Слить код в ветку релиза
   2. Разверните ветку релиза на работающем сайте

Почему проверка кода важна?

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

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

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

• Отсутствие опыта программирования
• Слабое знание системы
• Незнание правил коллектива
• Стресс развития
• Развитие под давлением времени
• Умственное истощение

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

Каковы наилучшие методы проведения проверки кода?

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

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

• Проверяйте не более 400 строк кода за сеанс: при большом объеме кода ошибки легко не заметить.
• Не проверяйте более 500 строк кода в час: в противном случае пострадает способность рецензентов обнаруживать ошибки.
• Ограничьте проверку кода максимум 60 минутами: при более длительных проверках кода проверяющим не хватает необходимой концентрации.
• Ставьте цели и собирайте метрики: сколько ошибок обнаружено в единицу времени или на строку кода?
• Авторы кода должны аннотировать исходный код перед рецензированием: аннотации направляют рецензентов через изменения кода и объясняют их.
• Используйте контрольные списки : они должны содержать элементы, которые рассматриваются во время каждого обзора.
• Установите процесс исправления обнаруженных ошибок : недостаточно просто отслеживать ошибки. Исправление ошибок требует четких указаний и структур.
• Продвигайте позитивную культуру код-ревью: ошибки следует представлять не как личную ошибку, а как возможность чему-то научиться.
• Использование подсознательных последствий рецензирования: когда известно, что код подлежит рецензированию, программисты прилагают к нему больше усилий.
• Используйте упрощенные процессы проверки кода. Современные инструменты проверки кода сделали проверку кода эффективной.

Каковы преимущества и недостатки проверки кода?

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

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

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

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

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

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

Недостатки проверки кода

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

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

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

Какие виды код-ревью существуют?

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

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

метод проверки кода	количество рецензентов	Преимущества	Недостатки
через плечо	1	Легко координировать	Результаты могут быть трудно контролировать
парное программирование	2	Высочайшее качество кода	Требует высоких профессиональных и личных качеств
электронная почта раунд	несколько	Относительно простой процесс	Может быть слишком сложным без инструментов
инструмент поддерживается	от 1 до нескольких	Высочайший уровень эффективности	Требуются инструменты

Обзоры кода через плечо

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

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

Верификация кода парным программированием

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

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

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

Проверка кода по электронной почте

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

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

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

Современные подходы к код-ревью используют специальные инструменты код-ревью. Они структурируют процессы обзора, повышают эффективность и собирают показатели. Инструменты делают процесс рецензирования планируемым, контролируемым и поддающимся проверке.

Существует множество доступных инструментов для проверки кода. Некоторые из них интегрированы в существующие подходы к непрерывной интеграции или непрерывной доставке (CI/CD). Мы представляем различные типы инструментов вместе с примерами.

Какие инструменты проверки кода существуют?

Инструменты проверки кода основаны на распределенных системах управления версиями (DVCS) и, в частности, на вездесущем Git.Они включают в себя функции отслеживания изменений в коде и их отображения в виде «отличий». Платформы на основе Git, такие как GitHub и GitLab, улучшают отображение и фокусируют внимание на командной работе. Благодаря своим мерж-реквестам эти платформы предлагают интегрированную проверку кода, прежде чем принимать новый код.

Инструменты проверки кода на основе DVCS

Эти инструменты используют Git или другую распределенную систему контроля версий (DVCS) в качестве основы. Исходя из этого, для организации проверки кода в команде обычно используется пользовательский веб-интерфейс. Некоторые инструменты проверки кода также имеют собственные интерфейсы командной строки (CLI).

GitHub

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

1. Клонировать репозиторий как локальную копию
2. Внесите изменения в свою ветку
3. Создайте запрос на вытягивание: вы просите сопровождающих репозитория просмотреть изменения и, если оценка положительна, объединить их с основным репозиторием.

Review board

Инструмент проверки кода Review Board выводит запросы на проверку на передний план. Современный и удобный веб-интерфейс предоставляет обзор всех запросов на проверку, выполняемых в репозиториях и филиалах. Его собственная команда rbt обеспечивает быстрый доступ из командной строки. В дополнение к коду в процесс рецензирования также могут быть включены графические изображения и PDF-документы.

Gerrit

Gerrit устанавливается на собственном сервере и действует как интерфейс между изменениями кода и производственной кодовой базой. Изменения проверяются код-ревью и вводятся в производство только в том случае, если они приняты. Установка Gerrit включает в себя самостоятельную среду Git с доступом по SSH и веб-интерфейсом, доступным через HTTPS. Помимо необязательных уведомлений по электронной почте, Gerrit включает систему голосования по изменениям кода.

Code Collaborator

Инструмент проверки кода Smart Bear Code Collaborator ставит пользовательские истории на первое место. Это ориентированные на пользователя спецификации функциональности, которые реализованы в коде и проверены тестами. Инструмент включает в себя менеджеров и группы тестирования в дополнение к команде программистов и позволяет последовательно просматривать изменения в пользовательских историях, коде и планах тестирования.

Инструменты для подготовки к код-ревью

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

Статический анализ также предоставляет метрики кода, такие как количество строк кода (LOC) на файл, класс или функцию. Линтер также может обнаруживать распространенные ошибки до проверки кода человеком. К ним относятся в т.ч. Ошибки ввода, SQL-инъекции и ошибки за пределами границ.

Инструменты для совместной разработки в реальном времени

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

Как веб-редактор Replit, так и LiveShare, интегрированный в редактор Microsoft VSCode, можно использовать в качестве редакторов HTML для совместной работы. Разумеется, оба инструмента говорят на других языках и допускают совместную работу с несколькими файлами и даже выполнение кода.