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

Исследования показали, что проверка дизайна и инспекция кода дают гораздо более высокую скорость обнаружения дефектов, чем тестирование программного обеспечения, о чём говорится в книге Стива МакКоннелла CodeComplete.

Но как максимизировать пользу от ревью кода — особенно при управлении распределённой асинхронной командой?

Сначала убедитесь, что ваша команда следует нескольким проверенным временем лучшим практикам. Во‑вторых, используйте современные инструменты, чтобы обеспечить совместную асинхронную коммуникацию. Приступим:

Как проводить ревью кода: 5 ключевых советов и лучших практик

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

1. Составьте чек‑лист для ревью кода

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

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

• Следуйте принципу KISS.
• Убедитесь, что новый код соответствует вашему существующему гайдлайну по стилю.
• Устраняйте актуальные уязвимости, чтобы обеспечить безопасность приложения.
• Используйте инкапсуляцию и модуляризацию, чтобы разделять зоны ответственности.
• Убедитесь, что покрытие тестами является достаточным.
• Там, где это имеет смысл, следуйте принципу DRY: по возможности используйте переиспользуемые компоненты, функции и сервисы.

2. Задайте лимит по времени ревью и количеству строк кода (LoC)

Наша способность к внимательной работе падает примерно через 60 минут, поэтому лучше, чтобы участники команды проводили более короткие сессии ревью кода, но чаще. Более короткое время также означает, что нужно установить лимит LoC для каждой сессии (например, около 200–400 строк). Фактически, отчёт Cisco показал, что способность программистов находить проблемы снижается после 200 строк.

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

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

3. Измеряйте прогресс с помощью правильных метрик

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

Скорость инспекции: время, которое ваша команда тратит на ревью определённого объёма кода. Она помогает оценить читаемость кода. 

• Частота дефектов: как часто ваша команда выявляет баг. Она показывает эффективность выбранного вами метода ревью.
• Плотность дефектов: количество дефектов в определённом объёме кода. Она помогает выявлять уязвимые компоненты и направлять на них больше ресурсов.

4. Давайте объективный и конструктивный фидбек

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

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

5. Настройте надёжные CI/CD‑пайплайны

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

Лучшие ревью кода для распределённых команд

Распределённым командам часто сложнее внедрять лучшие практики ревью кода из‑за отсутствия эффективных каналов коммуникации:

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

• А как насчёт скриншотов? Они избавляют вас от длинных описаний визуальных элементов словами, но статичное изображение не позволяет показать, как работают интерактивные компоненты во всём пользовательском потоке.
• Чат или личные сообщения добавляют интерактивности и способствуют обсуждению, но отсутствие структуры приводит к большому количеству переписки туда‑обратно. Кроме того, на большинстве платформ для личных сообщений легко потерять сообщение или ветку, из‑за чего становится сложно отслеживать договорённости.
• Видеозвонки обеспечивают обмен в реальном времени, но согласовать расписание бывает непросто. Длительные видеовстречи выматывают людей и снижают способность разработчиков замечать проблемы.

К тому же встречи не всегда являются наиболее рентабельным способом проведения ревью кода. Исследование показало, что команды разработки проводят 75% времени во встречах и 25% — за чтением. При этом чтение позволяет выявить 80% дефектов, а ревьюеры в 12 раз эффективнее находят проблемы при чтении, чем на встречах.

Как проводить эффективные ревью кода в асинхронных командах

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

Добавляйте контекст к обсуждению

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

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

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

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

Преобразуйте одностороннее ревью в двустороннюю коллаборацию

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

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

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

Сделайте процесс личным, уважительным и дружеским

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

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

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

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

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

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

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

Нет ни одной отговорки, чтобы не создать bubble уже сегодня: для начала не нужно регистрироваться, а вашей команде не придётся ничего устанавливать — достаточно браузера, чтобы просмотреть bubble. Всё, что вам нужно, — перейти по ссылке и записать свой первый bubble. Начните пользоваться bubbles, скачав наше расширение для Chrome, и убедитесь, как просто проводить эффективные ревью кода.

‍

‍