Привет, Хабр! Мы перевели статью, посвящённую не самой любимой задаче разработчиков — код-ревью. Как полюбить и превратить рутину в инструмент развития — в пересказе Medium.

Статья пригодится начинающим и опытным разработчикам, которые хотят упорядочить знания, оптимизировать процесс и получить практические советы.

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

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

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

Большинство разработчиков недолюбливает этот процесс по этим причинам:

1. Трата времени — нельзя знать заранее, сколько времени займёт проверка кода. Каждое изменение в основном коде проходит через код-ревью, в зависимости от количества изменений, этот процесс занимает от двух минут до двух часов.

2. Смена контекста — задача на код-ревью часто возникает в то время, когда специалист сосредоточен на других задачах. Приходится переключаться на новый процесс, что тормозит выполнение текущих задач и приводит к переключению контекста.

P.S. Не рекомендуется сразу же после получения уведомления бросаться делать ревью, поскольку переключение между задачами снижает продуктивность.

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

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

5. Отсутствие документации — отсутствие документации увеличивает время ревью, так как вам приходится постигать реализованную логику самостоятельно. Используйте автотесты и линтеры, принятые в команде.

Зачем это нужно?

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

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

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

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

Принять недостатки

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

Минимизировать недостаток и полюбить ревью помогут три рекомендации.

1. Выделяйте время

Структурируйте свой рабочий день так, чтобы у вас оставалось время для ревью. Если у вас на проекте внедрены спринты или канбан, вы можете определить среднее количество времени, которое вы тратите на ревью в течение недели. Разделите общее время на рабочие дни и выделите на ревью один час, например — с 11 до 12 ежедневно.

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

2. Составьте чек-лист

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

Чек-лист разработчика может выглядеть так:

• добавление требования к тикету в пул-реквест;

• добавление автоматизации кода;

• запуск инструментов, например, линтер, для исправления проблем с синтаксисом,

• выполнение внутреннего тестирования;

• написание unit тестов;

• запуск самого кода.

 3. Избегайте словесных перепалок

Часто код-ревью становится полем битвы разработчиков из-за различий в образе мыслей, стиле кода или стремлений защитить свою работу.

Здесь нужно приводить логичные комментарии, не поддаваться эмоциям и подкреплять мысли весомыми аргументами.

Если дискуссия превращается в спор, лучше предложить оппоненту обсудить моменты лично, вне ревью.

Советы для оптимизации

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

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

Вот 6 методов, которые подходят для авторов кода и ревьюеров:

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

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

3. Запустите код — в 90% случаев недостаточно просто посмотреть на код, чтобы найти ошибки. Проблемы обнаруживаются только при запуске и просмотре логов. В некоторых случаях для запуска кода может потребоваться особая конфигурация, подготовка которой должна быть частью процесса код-ревью.

4. Рефакторинг VS поддержка кода — баланс выбора между двумя процессами тонкий: во время ревью нужно подумать, в каких случаях разработчику нужно написать избыточный код или же провести рефакторинг. Здесь нет единственного верного ответа, на выбор будут влиять факторы: наличие времени у разработчика, возможность использования кода в других целях и вероятность регрессии. Оба процесса должны упростить ревью и улучшить код.

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

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

Несколько советов

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

2. Если ваши ревью объёмны и занимают много времени, предложите авторам кода делать изменения небольшими кусочками и создавать пул-реквесты по мере выполнения задач. Дозированную информацию проще ревьюрить.

Подытожим

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

Рекомендации и перечисленные практики из статьи рекомендуется использовать совместно и по отдельности. Методы помогут оптимизировать процесс и перебороть неприязнь к процессу.

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

Если вы тоже хотите поделиться фишками проведения код-ревью, что-то посоветовать или рассказать историю из опыта — пишите в комментариях.