Code review: принципы проведения, основные правила и рекомендации
Привет! Меня зовут Станислав Фелинский, и я Software Architect (Solution) в Gaming Unit’e компании Innovecs. В этой статье я поделюсь нашим опытом code review в контексте GameDev, его принципами и рабочими методами. Материал будет интересен не только авторам и рецензентам кода, но и всем инженерам команды.
Успешная стратегия проверки кода требует баланса между строго документированными процессами и благоприятной рабочей средой. Инженеры ответственны за поиск золотой середины, где проверка будет не только эффективной, но и будет способствовать открытому общению и обмену знаниями.
Предлагаю рассмотреть суть процесса, его главный фокус и какие практики помогают нам извлечь из него максимум пользы.
Иллюстрация Алины Самолюк
Зачем нужна проверка кода
Для начала хотелось бы поделиться нашими критериями к код-базе проекта:
- Гибкость (или же стойкость к изменениям).
- Оптимизация (или же скорость работы).
У проверки кода несколько ключевых задач:
- Предоставление обратной связи (feedback) автору для помощи в решение его задачи, при этом чтобы код-база проекта соответствовала критериям, описанным выше.
- Обмен знаниями как общими, так и конкретно по проекту, между автором и рецензентом.
Code review — это удобный инструмент, или, я бы даже сказал, часть SDLC, который можно использовать для достижения разного рода целей. Это прежде всего нужно рассматривать как инструмент обучения, совершенствования всей команды. Ведь учатся не только автор и рецензент друг у друга, но и другие участники. Непрерывное оттачивание знаний и скилов — одно из ключевых кредо компании, в которой я сегодня работаю.
Как проходит проверка и на чем базируется
В нашей команде процесс проверки кода состоит из таких этапов:
- Pull request.
- Review с комментариями:
- Merge, если замечаний нет;
- ToDo и правки, затем следует возврат к первому пункту.
Субъективно я бы сформулировал его следующим образом: Code review — как незаменимая часть рабочего процесса.
Для качественного ревью мы в команде используем такие подходы:
- Атомарные задачи. Каждая задача должна быть сформулирована таким образом, чтобы она затрагивала небольшую часть проекта. Мы используем формат User Story. В таком случае и автор, и рецензент фокусируются на небольшом участке кода, а следовательно, ревью проходит быстрее и качественнее.
- Gitflow. Одна задача решается в пределах одной ветки для одного проекта. Так мы можем гибко контролировать изменения код-базы.
- Ожидаемый объем работы — scope of work в пределах определенного отрезка времени. Для инженера важно понимать, какие глобальные задачи ему необходимо решить. Исходя из этого он сможет понять суть небольших атомарных задач и написать код для этого, а также прогнозировать время их выполнения с учетом ревью. С этой целью наша команда использует Sprints/Milestones.
Что касается инструментов проверки, то мы пользуемся Bitbucket и GitHub — выбор зависит от нюансов проекта, его особенностей. Эти сервисы имеют отличный, постоянно улучшающийся инструментарий для ревью кода. Кроме этого, они хорошо интегрируются с другими сервисами, которые являются частью нашего рабочего процесса.
Преимущества проверки кода
1. Последовательность в дизайне и реализации. Каждый инженер обладает своим уникальным стилем программирования и архитектурным мышлением. Применение разных стилей и архитектурных подходов существенно повышает энтропию проекта, что в итоге мешает совместной работе и замедляет прогресс в целом. Code review помогает с выбором тактик и методов в процессе работы над задачей. Такой подход стандартизирует исходный код, что позволяет всем инженерам (даже новым) легко его изучать и понимать. Также процесс полезен в долгосрочной перспективе, поскольку с ростом проекта масштабируется и команда. Поддержание согласованного стиля и архитектурного подхода поможет будущим инженерам инвестировать больше времени в работу над новым функционалом, а не в анализ существующего кода.
2. Сотрудничество и обмен новыми методами. В основном инженеры работают обособленно. Проверка кода способствует сотрудничеству и взаимодействию внутри команды относительно кода и обмену мыслями. Члены команды могут обмениваться информацией о новых знаниях во время проверки кода. Это помогает участникам проекта повышать свои навыки, узнавая о новейших технологиях, а также выстраивать доверительные отношения, что обязательно сказывается на конечном результате.
3. Мониторинг качества и требований проекта. Code review ассистирует инженерам команды, определяя области, в которых можно улучшить и оптимизировать работу приложения. Иногда автор может не знать о нюансах проекта или тонкостях оптимизации. Процесс проверки кода помогает им получить фидбэк от коллег и, следовательно, отточить свои навыки. Кроме того, в процессе code review можно выявить критические ошибки, которые в конечном итоге могут привести к серьезным багам. Можно сделать вывод о том, что ревью кода существенно повышает ценность цикла разработки для создания качественных продуктов.
Если говорить о недостатках ревью, то, на мой взгляд, их нет. Вероятно, можно сказать, что проверка тормозит рабочий процесс. Но я бы ответил на это следующим образом: это инвестиция времени, которая в будущем полностью окупится, ускорит процесс разработки и улучшения продукта. Задачи без code review формально можно закрыть быстрее, но в конечном итоге получить код-базу проекта, которую невозможно поддерживать. Иногда из-за этого проект может так и не стать продуктом.
После того как мы в команде настроили процесс code review, начали использовать общие знания и наработки между несколькими проектами отдела. Фактически проекты частично стали использовать общую код-базу, помогать друг другу, благодаря чему пропал дубляж кода.
Культура обратной связи: лайфхаки
В 99% случаев code review в нашей команде проходит в письменной форме. Поэтому крайне важно правильно формулировать свои мысли в комментариях — читающий человек может неправильно воспринять ваши тон, настроение и посыл. Иногда это приводит к напряженным отношениям и конфликтным ситуациям, что плохо сказывается на результатах.
В нашей команде используют следующие подходы:
- В команде нет «ты» и «я», команда — это «мы». Только командная работа может привести к хорошему результату. Не стоит переходить на личности, это относится не только к code review, но и к отношениям в команде в общем. Например: «Нам стоит разделить этот интерфейс...» вместо «Тебе нужно это исправить...»
- Все комментарии должны быть обоснованы. Любое замечание нужно подкрепить ссылкой на литературу (статью, документация и так далее) или примером из личного опыта. Например: «...этот класс противоречит принципу L из SOLID...» или «...на предыдущем нашем проекте это привело к падению FPS до 5...»
- Не указывать только на проблему — предложить решение. Нельзя забывать, что автор приложил огромные усилия при решении задачи, а цель рецензента — помочь. Потому комментарий «Это нужно переделать» не имеет смысла. Очень важно предложить свой вариант решения. Например: «Этот класс противоречит принципу L из SOLID, потому нам стоит сделать еще один уровень наследования».
- Хороший способ описать решение — предоставить свой пример кода. Любому инженеру пример кода объяснит ход ваших мыслей лучше тысячи слов. Иногда бывает так, что решение не приходит сразу, но опыт и интуиция подсказывают, что участок кода требует внимания. В этом случаем мы обсуждаем проблему вместе с коллегами и ищем решение или же заводим задачу для этого на будущее.
И еще пару советов напоследок
Автор и рецензент обязаны подходить к проверке кода ответственно. Автору стоит посмотреть свой код (pull request) самостоятельно перед отправкой на предмет ошибок, которые он может исправить сам. Идеальное решение — автоматизация. Если она еще не готова, то за это несет ответственность автор. Рецензент должен провести ревью без задержек и с максимальной вовлеченностью.
В нашей команде мы договорились о времени суток для ревью — утро каждого рабочего дня. Это помогает планировать свое время всем инженерам команды — как авторам, так и рецензентам. Для меня утро — самая продуктивная часть рабочего дня, а ревью — одна из самых ответственных задач. Таким образом можно дать дельные советы, смотря на код свежим взглядом.
14 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів