Как проходит процесс review кода? Основные правила

В процессе работы разработчикам нередко приходится переписывать код и вносить изменения, чтобы все работало без багов. Из-за доработок глаз буквально «замыливается», а анализаторы не всегда эталонно доводят стиль кода до установленных стандартов.

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

Как уже говорилось, code review является процессом обмена опытом, а не массового осуждения и критики. Соответственно, в рамках кода-ревью более опытные коллеги дают рекомендации, выявляются неочевидные ошибки, обосновывают свои решения — растет компетенция как отдельных специалистов, так и команды в целом. 

На практике, мотивированные специалисты охотно включаются в code review, особенно, если они занимаются позиции уровня junior и middle.

Само-ревью: проводится, когда в проекте работает только один разработчик. Он самостоятельно повторно проверяет свой код. При само-ревью лучше следовать чек-листу, а также исключить чтение кода по диагонали. Желание сдать работу пораньше и побыстрее вполне понятно, но формальная отписка «approve» может стать причиной краха последующих работ. Стоит задача отловить баги самостоятельно, поэтому лучше чекать строки дробно: например, по 50–100 строк, делая небольшие перерывы между code review.

Ревью через техлида: код проверяет технический лидер проекта. Он проводит глубокий анализ качества, выявляет соответствие кода стандартам разработки, оценивает возможность улучшения кодовой базы и очерчивает потенциальные проблемы. Лидер направления после code review возвращает разработчику задачу: после доработок он повторно выполняет анализ. Ревью через тех-лида наиболее распространенный вид code review.

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

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

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

До code review разработчики Kokoc.tech проверяют код через git-hooks. Он в автоматическом режиме проверяется стиль, выявляет отступы и базовые ошибки. При таком подходе техлид и команда не тратят время на очевидные недочеты, которые может разработчик скорректировать самостоятельно до code review.

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

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

В рамках code review ревьюер может проверить функциональность кода, провести тесты — полная свобода действий с учетом поставленных задач и специфики проекта!

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

Простая задача может занять на ревью около 15 минут, более сложная — до часа и более. Тайминг зависит от размера файла и количества строк. Задачи, которые «по коду» кажутся короткими, в итоге требуют больше часов. К тому же стоит понимать, что в процессе code review необходимо делать паузы: проверка требует концентрации, внимания, сосредоточенности. Поэтому нет смысла проверять код более часа без перерывов. Иначе может снижаться качество анализа.

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

В Kokoc Tech выработаны свои алгоритмы и принципы code review:

• Все задачи проходят код-ревью, если над проектом работает больше одного разработчика.
• Простые баг-фиксы (например, изменение текста или цвета кнопки) могут выкатываться без ревью, если разработчик уверен в своем решении.
• Для автоматизации у нас используются git-hooks, который отрабатывают перед тем, как разработчик отправляет свой код в gitlab и на ревью. Это избавляет ревьюера от необходимости проводить дополнительные проверки и тратить время на базовый анализ.
• Ответственным за код-ревью обычно является техлид проекта. Тимлид всей команды привлекается не всегда.
• Замечания и комментария пишутся обезличенно и доброжелательно. Желательно аргументация, а сами комментарии выстраиваются в формате просьбы.
• Разработчики не воспринимают замечания на свой счет, и нет личностных обид. Авторы адекватно воспринимают критику за счет правильно выстроенных отношений внутри коллектива и создания доверительной атмосферы.
• Мы используем проверки на название ветки, название коммита, в соответствие с регламентами компании.

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

Код-ревью — это не только контроль, но и инструмент развития специалистов и повышения качества продукта разработки. 

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