Как сделать обзоры кода эффективнее?

General, Java, Python | Amber | Комментировать запись

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

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

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

Вне зависимости от платформы, на которой вы работаете – GitHub, GitLab, Gerrit или что-то другое – вы должны научиться извлекать из процесса проверки кода как можно больше пользы, и эта статья поможет вам сделать это.

Зачем вообще нужен обзор и анализ кода?

Обзор и анализ кода затрагивают широкий диапазон контекстов, и часто участники имеют очень разные навыки и опыт. Например, в проектах с открытым исходным кодом участники команды могут не иметь каких-либо личных отношений друг с другом – возможно, они вообще никогда не общались лично и за пределами процесса проверки кода. С другой стороны, бывают команды, в которых участники ежедневно общаются (например, когда все работают не удаленно, а в одном офисе). Так или иначе, степень знакомства участников обзора может сильно повлиять на качество процесса. Конечно, стиль общения в команде зависит от личных отношений в команде разработчиков.

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

Определение цели обзора кода

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

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

Какие изменения следует включать в код?

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

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

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

Письменное обсуждение технических аспектов приложения может быть затруднено (время участников ограничено и т.д.). В обзорах кода каждый участник должен играть определенную роль. Каждая роль имеет свой набор целей:

• «писатель» должен постараться наиболее четко и ясно изложить суть изменений. Не расстраивайтесь, если ваш патч не был рассмотрен в выбранные вами временные рамки.
• «читатель» должен задавать вопросы, если что-то непонятно.
• «рецензентам» следует быть вежливыми и проявлять уважение – ведь для подачи патча в ваш проект разработчик потратил свое время.

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

Работа в команде

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

Подготовьте и отправьте свои отзывы после прочтения всего кода. Будьте вежливы. В комментариях постарайтесь сосредоточить внимание на коде и предлагаемом ими решении; не стоит отвлекаться на посторонние вопросы. Если вы видите что-то непонятное в коде, задавайте вопросы. Если вы лично не знакомы с автором, приложите дополнительные усилия, чтобы сообщить о своих благих намерениях.

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

Внимательно изучите отзывы, оцените их и решите, что делать дальше. Авторам бывает сложно принимать критику кода. Когда рецензент задает вопросы по коду, его цель – не оскорбить автора, а улучшить продукт. Напомните себе, что отзывы о коде не несут в себе ничего личного. Вы можете принять отзыв во внимание и что-то изменить в коде. Или же вы можете решить, что некоторые предлагаемые изменения необоснованны или просто ошибочны и не добавляют никакой ценности. Не бойтесь отстаивать свое мнение, но делайте это вежливо.

Обзоры кода и развитие сотрудничества

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

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

Успешный обзор кода повысит качество изменений, укрепит отношения между рецензентом и автором и повысит вовлеченность разработчиков в проект. Обзоры и анализ кода – это не просто формальность перед слиянием кода; это важный аспект современной разработки программного обеспечения.

Заключение

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