Ревью кода — нелегкая работа! Инженеры-программисты часто жалуются на то, что проверка идет медленно, тормозит выполнение последующих задач и приводит к переключению контекста, когда вы снуете туда-сюда между открытым пул-реквестом (PR) и очередным заданием. Ревью кода может сопровождаться мелкими замечаниями и бесконечными обсуждениями малозначимых деталей, что в итоге портит настроение всех участников процесса.
Дошло до того, что некоторые программисты предложили кардинально решить проблему и вообще отказаться от пул-реквестов и ревью. Возможно, для небольших команд в стартапах это и сработает. Однако сомневаюсь, что такой вариант подойдет всем остальным, особенно компаниям корпоративного уровня.
Но зачем впадать в крайности, когда есть много способов оптимизировать процесс ревью кода как для автора, так и для рецензента. Предлагаю вашему вниманию 7 лучших практик такого рода.
#1. Создание небольших пул-реквестов
Страшный сон любого инженера-программиста — проверка пул-реквеста, содержащего более 1000 строк измененного кода. На такие ревью уходят часы работы, и все заканчивается тем, что вместо внимательного изучения рецензент начинает бегло просматривать код.
В связи с этим настоятельно рекомендуется создавать небольшие пул-реквесты. В таком виде их легче и быстрее проверять, поскольку рецензент сразу понимает принцип совместной работы всех изменений. Кроме того, чем меньше изменений в коде, тем меньше ошибок и комментариев, а также короче диалог между автором и рецензентом.
Сначала задача по созданию небольших пул-реквестов покажется сложноватой. Советую разбивать работу на небольшие задачи и концентрироваться на них. Не следует проводить важный рефакторинг одновременно с реализацией новых функциональностей или исправлением ошибок. Используйте в коде так называемые фича-флаги (англ. feature flag). Они позволяют проводить слияние небольших частей новых функциональностей с основной веткой master без отображения их в продакшн-приложении.
Соблюдайте небольшой размер пул-реквестов, и рецензенты будут вам благодарны!
#2. Применение шаблонов пул-реквестов
Еще один раздражающий фактор для рецензента — проверка пул-реквеста без контекста. Представьте, что вам пришел PR без всяких объяснений. Приходится гадать: “Зачем он нужен?”, “Какую задачу решает?”, “Связан ли он с другой задачей?”, “Почему выбран именно такой подход?”.
Шаблон представляет собой компактную настраиваемую форму контрольного списка, которая устанавливается в качестве текста по умолчанию для каждого нового пул-реквеста. Он побуждает автора кода сопроводить PR соответствующей информацией. Как правило, такой шаблон предусматривает краткое описание выполненных действий и их обоснование, ссылку на тикет задачи, а также план тестирования для проверки правильности изменений.
Грамотно составленные шаблоны пул-реквестов обычно включают короткий список контрольных вопросов. Отвечая на них, автор может убедиться, что не упустил из виду ни одного важного момента. Перечислим примерные пункты подобного списка: модульные тесты, документация, интернационализация, поддержка кроссбраузерности и доступность.
Ниже представлен пример шаблона, который применяется для всех моих репозиториев:
#3. Ревью кода за установленное время отклика SLA
Допустим, вы видите, что пул-реквесты остаются не проверенными дольше положенного. Что делать? Самое время обсудить внутри команды сроки для обязательного просмотра новых PR. Иначе говоря, как долго пул-реквест может оставаться без внимания? Один час? Два? Сутки? Ответ на вопрос зависит от численности команды. Сроки, установленные для внутренних пул-реквестов от “своих” и внешних от других команд, могут разниться.
Выбирая время отклика SLA (англ. Service Level Agreement, т.е. Соглашение об уровне обслуживания), вы можете найти баланс. Наивно думать, что ваши коллеги немедленно бросят свои дела и займутся ревью кода, как только вы опубликуете новый пул-реквест. Но при этом вы вряд ли смиритесь с тем, что несколько часов подряд он остается без ответа. Найти “золотую середину” — вот задача, стоящая перед вами. Это позволит наладить плавный рабочий процесс в команде: ваши коллеги успеют не только поработать над своим кодом, но и проверить пул-реквесты в перерывах по ходу дня.
На мой взгляд, оптимальный вариант времени отклика SLA для внутренних PR — 2 часа, а для внешних — 24 часа.
Независимо от содержания совместно принятых решений, наличие командного соглашения возлагает на каждого ответственность за его соблюдение. Если все одобрили конкретное время отклика SLA, оно истекло, а пул-реквест еще не проверен, то вы в праве напомнить коллегам о взятых на себя обязательствах.
#4. Обучение менее опытных программистов
Возможности обучения повсюду. Руководство менее опытными программистами не ограничивается только предоставлением им знаний о технологиях и языках, с которыми они работают. Оно также подразумевает формирование у них таких навыков, как эффективное выполнение ревью кода.
Проинформируйте коллег по команде, каких действий вы ждете от них при проверке кода. Разъясните им приоритеты в работе. Научите их продуктивно общаться в комментариях к ревью, например сопровождать неблокирующие рекомендации префиксом nit (сокр. от nitpick).
Стать более продуктивным рецензентом кода помогают самые разные ресурсы. Например, вы не пожалеете, если полностью прочитаете руководство Google для разработчиков по ревью кода. Там есть много полезных рекомендаций как для авторов, так и для рецензентов. А вот в статье How to Make Your Code Reviewer Fall in Love with You (“Как влюбить в себя вашего рецензента”) автор в дерзкой и увлекательной манере делится лучшими советами по созданию пул-реквестов.
#5. Настройка конвейеров непрерывной интеграции
Ревью кода начинают утомлять, когда большинство комментариев сводятся к таким замечаниям, как “Отсутствует точка с запятой” или “Неправильные отступы”. Не тратьте время на то, с чем могут легко справиться инструменты форматирования и проверки стандартов оформления кода. Пусть компьютеры автоматизируют работу с мелочами, а вы займетесь более важными делами.
Для проектов JavaScript проще всего сначала в репозитории настроить такие инструменты, как Prettier и ESLint, а затем — непрерывную интеграцию посредством Travis CI, CircleCI, GitHub Actions и GitLab CI/CD.
Конвейер CI возьмет на себя выполнение задач по форматированию и проверке стандартов оформления кода наряду с модульными тестами. Застопорившись на каком-либо этапе пул-реквеста, он заблокирует его слияние.
Автоматизация нескольких этапов ревью кода экономит часы работы.
#6. Использование приложений для ревью кода
Иногда необходимо не только проверить код в пул-реквесте, но и вручную просмотреть изменения в приложении и убедиться, что все работает как положено. Если приложение отличается сложными этапами настройки, то извлечение чужого кода и его локальный запуск на компьютере занимают от 5 минут до 1 часа. А это проблема!
Приложения для ревью кода автоматически развертывают код в краткосрочной тестовой среде при каждом создании нового пул-реквеста. В этом случае рецензенты проверяют изменения UI, обходясь без извлечения кода и локального запуска на компьютере. Такой подход не только экономит время, но побуждает рецензентов к более внимательной проверке кода, упрощая сам процесс ревью.
#7. Создание диаграмм для визуализации изменений в коде
При проверке кода на GitHub или GitLab файлы, как правило, отображаются в алфавитном порядке. Для сравнительно небольших пул-реквестов это вполне подходит. Но если PR включает десятки файлов, то целесообразно представить эти изменения в логически структурированном виде. Так мы лучше поймем, как они согласуются в общей картине.
Карты CodeSee для ревью кода наглядно отображают, какие файлы были изменены и как эти изменения влияют на их предыдущие и последующие зависимости. Они интегрируются с GitHub для автоматической публикации комментария и диаграммы к пул-реквесту. В помощь рецензентам можно даже создавать интерактивные маршруты по коду. А самое главное преимущество карт CodeSee состоит в том, что они предоставляются бесплатно для организаций с открытым исходным кодом и их публичных репозиториев.
Заключение: лучшие практики для быстрого ревью кода
Подведем итоги и еще раз перечислим 7 рекомендаций, благодаря которым вы значительно сокращаете временные затраты на ревью кода.
- Создавайте небольшие пул-реквесты.
- Используйте шаблоны пул-реквестов для обеспечения всего необходимого контекста для рецензента.
- Устанавливайте время отклика SLA.
- Обучайте менее опытных программистов ключевым аспектам ревью кода.
- Настраивайте конвейеры CI для выполнения форматирования, проверки стандартов оформления кода и модульных тестов.
- Задействуйте приложения для ревью кода для упрощенной проверки изменений UI.
- Создавайте диаграммы для визуализации изменений в коде с помощью карт CodeSee для ревью.
Читайте также:
- Основные правила код-ревью
- Как оптимизировать пулл-реквесты и порадовать тех, кто проверяет ваш код
- Автоматизируйте код-ревью и ускорьте итерации
Читайте нас в Telegram, VK и Дзен
Перевод статьи Tyler Hawkins: 7 Ways to Dramatically Reduce Your Time in Code Review
