Почему разработчики-джуниоры должны ревьюить коммиты сеньоров

Перевод статьи «Why junior devs should review seniors’ commits».

Ревью кода

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

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

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

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

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

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

Польза для команды

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

Те же приемы вполне применимы между командами и между людьми с разными компетенциями. Почему бы embedded-разработчикам не делать ревью GUI-кода или бэкенд-разработчикам – ревью некоторых фронтенд-изменений? Если что-то выходит за пределы их основной зоны компетенции, это еще не значит, что они неспособны выявить ошибку или дать отзыв. Хотя более тонкие детали, имеющие отношение к конкретным библиотекам и языкам, в любом случае должны просматриваться человеком, хорошо знакомым с этой сферой.

Так что давайте делать ревью по большей части кода и при этом задействовать всех, от джуниоров до сеньоров.


[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]

Оставьте комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Прокрутить вверх