Большинство разработчиков не любит проводить код-ревью. Все понимают, что это важно и нужно, могут с ходу назвать три-четыре причины необходимости этого процесса. Но раз за разом они всячески избегают его. Или участвуют в нём неэффективно.
Поэтому разрушим шаблоны — не будем акцентировать внимание на важности и полезности код-ревью, а разберёмся в причинах сложившейся неприязни к этому процессу. И попробуем понять, как с этим жить.
Перед тем, как вы начали читать:
да, здесь будут клише, которые все знают. Но мы про них всё равно расскажем;
да, здесь будут любопытные предложения и мысли;
да, будут и те, прочитав которые, вы скажете «детский сад!». Но суровая правда жизни показывает, что детского сада в нашей сфере становится всё больше и больше;
будут даже такие, увидев которые, вы воскликните «Да это же бред! Это не сработает!»
Но просто попробуйте. Мысли из этой статьи проверялись на практике. При этом они подойдут не всем командам. Собранные здесь советы — далеко не самое главное. Запомните эту мысль — мы вернёмся к ней в конце статьи.
Вернёмся к теме. Почему же разработчики не горят желанием проводить код-ревью? Разделим возможные причины на три сегмента:
внешние и внутренние факторы;
откровенно плохой код;
и большая, но весомая, внутренняя причина под названием лень.
Внешние и внутренние факторы
Перед тем, как что-то писать о код-ревью, мы в компании провели исследование среди мобильных разработчиков. Выборка небольшая, состоит из 38 человек, но оттолкнёмся от результатов этого опроса.
Вопрос звучал так: «Что мешает приступить вам к код-ревью?»
А результаты были следующими:
Мы используем термин PR — pull requst, он же merge request. И исходим из того, что любой PR должен пройти код-ревью перед его «мёржем» в рабочую ветку.
Разберём каждую причину подробно и расскажем, что делать для исправления ситуации.
Большой PR, большое количество изменений
Многие не хотят смотреть на большие изменения — большой diff — такие PR могут быть сложными для восприятия.
Что делать автору PR, если всё-таки большое количество изменений неизбежно:
если этот вопрос появился на этапе создания PR — сожалеем, но вы уже опоздали. Следовало разбить задачу на более мелкие и выкладывать каждую в отдельном PR (если это допускается на проекте);
если задача уже в разработке, изменений много, но вы хотите облегчить жизнь команде — реализуйте решение в рамках нескольких PR. Укажите, какая часть выполнена и сколько частей ожидается. Если скрипты двигают задачи в таск-трекере — этот пункт может быть неактуальным;
постарайтесь покрыть хотя бы часть кода тестами. Они покажут (если написаны правильно) надежность изменений — и уже меньшее количество ревьюверов будет бояться код-ревью;
разбейте один PR на логические коммиты, чтобы ревьюер мог просмотреть каждую часть отдельно;
не добавляйте в задачу сторонние правки — оставайтесь в рамках текущей задачи;
делайте паузы во время работы, чтобы оценить объем изменений и понять, нужно ли разбивать PR на части.
Что делать ревьюверу? Поговорить с командой, попробовать изменить процесс, сделать его проще и удобнее. Ну, или страдать
Интересные статьи
Интересные статьи
