Наши разработчики постоянно работают над новыми проектами и совершенствуют IT-процессы, чтобы продукты были качественнее, а работа над ними — эффективнее. Но новые функции не сразу внедряются в проект. Сначала код отправляется на код-ревью, то есть на проверку.
Поговорили с Тимуром Боргалиновым, разработчиком KazanExpress, и узнали, что такое код-ревью, в чем особенности этого процесса и как добиться более качественного результата.
Что такое код-ревью и зачем он нужен?
Код-ревью — это процесс контроля и улучшения качества продукта. С его помощью вы понимаете, что задача выполнена в полном объеме, что соблюдены все правила и договоренности, что решение не избыточно, его легко поддерживать и масштабировать в будущем.
Перед тем как заняться внедрением или улучшением код-ревью, нужно задать своей команде пару вопросов:
- Сколько в среднем времени занимает ревью кода?
- Как у вас в команде понимают, что ревью было сделано правильно?
- Пытаетесь ли вы уменьшить время ревью? Если да, то как?
Ответив на эти вопросы, вы сможете оптимизировать код-ревью конкретно для вашей команды.
Чем грозит некачественный код-ревью?
- Снижается скорость работы над проектом. Не все быстро отвечают на запросы из-за обилия задач, и это тормозит работу команды. Исправления замечаний могут затянуться на недели.
- Медленные ревью препятствуют рефакторингу (изменению кода, облегчающему понимание) и дальнейшим улучшениям.
- Разработчики начинают выступать против код-ревью. Если ревьювер (тот, кто проводит код-ревью) отвечает только через несколько дней, но каждый раз запрашивает существенные изменения, — это неприятно. Начинаются жалобы на то, что ревьювер слишком «строг». При этом, если он запрашивает те же изменения, но реагирует быстро, жалобы исчезают. А значит, проблема кроется не в «строгости», а в скорости ответа.
Что поможет выполнять код-ревью быстрее?
Если вы не в середине задачи, требующей концентрации, то лучше сделать код-ревью сразу. Один рабочий день — максимальное время для ответа. Например, поставьте ревью на следующее утро — так в течение одного дня можно успеть пройти несколько раундов ревью, если они нужны.Иногда стоит поставить приоритет на собственной скорости работы. Если вы делаете сложную задачу — например, пишите код, — не стоит отвлекаться на код-ревью. Исследования говорят о том, что у разработчика вход в контекст после отвлечения занимает слишком много времени. И поэтому отвлечение от кодинга обходится компании не дешевле, чем просьба немного подождать. Сначала сделайте свою работу, а к код-ревью вернитесь после завершения задачи.
Что поможет улучшить качество код-ревью?
1. Командное владение кодом
Здесь важно оценить bus factor — критерий, который показывает, как рассредоточены знания в проекте. Он дает понять, без какого количества разработчиков работа не может быть продолжена. Высокий bus factor означает, что проект будет устойчиво развиваться, даже если его покинет большая часть команды. Низкий — когда знаниями владеют конкретные люди, от работы которых зависит успешное функционирование продукта. Изменение bus factor — важный поинт ревью кода. Нужно, чтобы каждый кусок в коде проверял не один член команды и знания не принадлежали кому-то конкретному.
2. Переиспользование кода
Это когда несколько человек, решающих разные задачи и обладающие разными знаниями о продукте, проверяют код друг друга. В этом случае выше вероятность того, что они могут заметить определенные закономерности и предложить использовать уже готовое решение или вынести текущее в отдельный модуль.
3. Обмен знаниями внутри команды
У каждого в команде есть чему поучиться. Кто-то хорош в алгоритмах, другой разбирается в базах данных, третий — мастер операционных систем. Возможность посмотреть на решения друг друга и задать вопросы — это отличный способ поднять технический уровень всей команды.
4. Выявление ошибок
Наиболее очевидная цель код-ревью — это выявление ошибок разной степени критичности. Именно об этом в первую очередь думает ваш product manager, когда вы предлагаете ему заложить время на код-ревью.
5. Единообразие и простота проекта
Сколько на свете людей, столько и разных взглядов на то, как именно нужно писать код. Табы и пробелы, файловая структура проекта — при отсутствии консистентности они могут сильно усложнить чтение и анализ кода.
6. Рефлексия или self-review
Большую часть ошибок в своем коде автор способен распознать сам. Поэтому перед тем как отправить свой код на ревью, стоит хоть раз внимательно его просмотреть. Эта простая процедура поможет сэкономить время и нервы.
7. Чек-листы и автоматизация
Запоминайте вопросы, которые часто возникают у команды на ревью, и заносите их в чек-лист. Главное — не давать документу разрастаться. Думайте о способах автоматизации каждой из перечисленных там проверок. Если приложить достаточно усилий, большую часть вопросов вы сможете закрыть сами. Есть огромное количество инструментов, которые могут помочь в этой работе: линтеры, статические анализаторы, детекторы дублирующегося кода — например, SonarQube помогает с непрерывным анализом и измерением качества программного кода.
8. Архитектурные встречи
Код-ревью — не самое подходящее место, чтобы спорить по поводу глобальных архитектурных решений. Код уже написан, решение выкачено, задача почти доделана. Переписывать с нуля — слишком затратно и часто не оправдано. Такие вещи нужно не оставлять на потом, а обсуждать заранее. Например, можно провести архитектурную встречу с защитой и аргументацией своего решения перед командой — либо на словах, либо в виде схемы. Иногда, когда кого-то осеняет уже во время ревью и предложение оказывается ценным, стоит задокументировать идею в issue-трекере (системе поиска ошибок, — прим. ред.) и вернуться к ней при необходимости.
Как общаться с разработчиками во время код-ревью, чтобы не раздуть конфликт?
- Будьте вежливы.
- Объясняйте свои рассуждения.
- Позволяйте разработчику решать проблемы самому.
- Поощряйте разработчиков упрощать код.
Хороший пример коммуникации: «Использование этой библиотеки тут лишнее, так как она добавляет слишком много функционала, которым мы пока не пользуемся. Думаю, в этом случае было бы целесообразнее взять только нужную часть и использовать ее в новом модуле».
Плохой пример коммуникации: «Зачем ты запилил эту либу? Где вообще нашел ее? Переделывай все».
Иногда ревьюверу кажется, что разработчик упадет духом, если настаивать на изменении кода. Да, правки болезненны, но вам скажут спасибо за то, что помогли улучшить качество кода. Чаще всего, если вы вежливы и аккуратны в своих комментариях, они вовсе не переживают, а беспокойство находится только в голове ревьювера.
Если видите какое-то крутое решение у разработчика, скажите ему об этом. Особенно это ценно, когда разработчик в лучшем виде решил проблему, изложенную в одном из ваших комментариев. С точки зрения менторинга, иногда даже более важно сказать, что именно человек сделал правильно, чем то, где он ошибся.
Когда разработчик не согласен с вашим комментарием как ревьювера, найдите время рассмотреть его позицию. Он ближе вас к коду, у него действительно может быть более объективное представление. Есть ли смысл в его аргументе с точки зрения качества кода или бизнес-решения? Если да, то признайте его правоту, и вопрос отпадет.
Но разработчики правы не всегда. Тот, кто проводит ревью, должен объяснить, почему его предложение верное. Хорошее объяснение демонстрирует понимание ответа разработчика и содержит дополнительную информацию о том, почему требуется изменение. Когда ревьювер считает, что его предложение улучшит качество кода и полученное улучшение качества оправдывает дополнительную работу, он должен настаивать на решении.
Иногда требуется несколько раундов объяснений, прежде чем изменение будет принято. Просто убедитесь, что всегда остаетесь вежливыми, и пусть разработчик знает, что вы его слышите.
Главное правило код-ревью — не бежать за идеалом
Не бывает идеального кода, бывает только код «получше». Не стоит требовать от автора полировать каждый крошечный кусок. Команда должна стремиться не к идеалу, а к непрерывному улучшению кода.
