Привет, Хабр! Мы перевели статью, посвящённую не самой любимой задаче разработчиков — код-ревью. Как полюбить и превратить рутину в инструмент развития — в пересказе Medium.
Статья пригодится начинающим и опытным разработчикам, которые хотят упорядочить знания, оптимизировать процесс и получить практические советы.
Почему разработчики не любят код-ревью
Сразу оговоримся — разработчики любят чужой код, но грамотный, написанный по общепринятым стандартам и с логичными комментариями.
Программисты не любят ревьюрить код, написанный безграмотно и запутанно, без соблюдения стиля и нужной документации.
Большинство разработчиков недолюбливает этот процесс по этим причинам:
1. Трата времени — нельзя знать заранее, сколько времени займёт проверка кода. Каждое изменение в основном коде проходит через код-ревью, в зависимости от количества изменений, этот процесс занимает от двух минут до двух часов.
2. Смена контекста — задача на код-ревью часто возникает в то время, когда специалист сосредоточен на других задачах. Приходится переключаться на новый процесс, что тормозит выполнение текущих задач и приводит к переключению контекста.
P.S. Не рекомендуется сразу же после получения уведомления бросаться делать ревью, поскольку переключение между задачами снижает продуктивность.
3. Разница во мнениях — часто автор и ревьюер спорят об изменениях. Оба приводят аргументы в пользу предложенного решения, ищут способ реализации, который устроит автора и ревьюера.
4. Стиль кода — большинство проектов имеют свой стиль, который нужно соблюдать. Если же он отсутствует, то процесс ревью усложняется, так как нет чёткого видения стиля.
5. Отсутствие документации — отсутствие документации увеличивает время ревью, так как вам приходится постигать реализованную логику самостоятельно. Используйте автотесты и линтеры, принятые в команде.
Зачем это нужно?
Несмотря на негативное отношение к код-ревью, это та вещь, которая превращает хорошего разработчика в отличного. Задача помогает понять, как мыслят другие разработчики, и косвенно поучаствовать в создании проектов.
Код-ревью — практический способ расширить свою базу знаний, сделать свой вклад в проект и помочь другим разработчикам.
Техника помогает на ранних стадиях найти некоторые ошибки и избавиться от непонятных и запутанных решений. В работе над кодом участвует не один человек, а команда проекта, поэтому часто может появиться свежий взгляд со стороны.
Программист, который заранее знает, что коллеги будут проверять его работу, стремится писать более аккуратно и организованно. В итоге, код получается более качественным, его понимают несколько человек, а процесс ревью ускоряется.
Принять недостатки
Главный и единственный недостаток этого процесса — его длительность. Все участники код-ревью тратят время на то, чтобы посмотреть и при необходимости прокомментировать код, а разработчики — на исправление ошибок.
Минимизировать недостаток и полюбить ревью помогут три рекомендации.
1. Выделяйте время
Структурируйте свой рабочий день так, чтобы у вас оставалось время для ревью. Если у вас на проекте внедрены спринты или канбан, вы можете определить среднее количество времени, которое вы тратите на ревью в течение недели. Разделите общее время на рабочие дни и выделите на ревью один час, например — с 11 до 12 ежедневно.
Такой подход позволит постоянно находить время для ревью, причём об этом будете знать и вы, и ваша команда. Раннее планирование заметно облегчит вам жизнь.
2. Составьте чек-лист
Чек-лист упрощает процесс ревью для разработчика. Стандартный чек-лист включает в себя две и более колонки: задача, промежуточные этапы, выполнение.
Чек-лист разработчика может выглядеть так:
добавление требования к тикету в пул-реквест;
добавление автоматизации кода;
запуск инструментов, например, линтер, для исправления проблем с синтаксисом,
выполнение внутреннего тестирования;
написание unit тестов;
запуск самого кода.
3. Избегайте словесных перепалок
Часто код-ревью становится полем битвы разработчиков из-за различий в образе мыслей, стиле кода или стремлений защитить свою работу.
Здесь нужно приводить логичные комментарии, не поддаваться эмоциям и подкреплять мысли весомыми аргументами.
Если дискуссия превращается в спор, лучше предложить оппоненту обсудить моменты лично, вне ревью.
Советы для оптимизации
Код-ревью — процесс, порой, долгий и трудоёмкий. Проверка кода может сопровождаться мелкими замечаниями и бесконечными обсуждениями малозначимых деталей, что отнимает несколько часов времени у всей команды.
В порыве эмоций некоторые программисты даже предлагали кардинальные меры — вообще отказаться от пул-реквестов и ревью. Идею не поддержали, и это верное решение, потому что есть эффективные способы оптимизировать процесс ревью.
Вот 6 методов, которые подходят для авторов кода и ревьюеров:
1. Пройдитесь по техническим требованиям — это должно стать отправной точкой код-ревью, чтобы избежать ошибок и траты времени. Часто разработчики упускают требования в начале ревью, а они могут дублироваться или существенно меняться с момента своего создания, поэтому решение часто отклоняется от них, а в некоторых случаях написанный код вообще не связан с требованиями.
2. Комментируйте только изменения — не тратьте время на комментирование изменений, несвязанных с пул-реквестом, даже если считаете его неверным. Из-за этого код-ревью занимает гораздо больше времени, чем было запланировано. Можно использовать шаблон пул-реквестов, чтобы предусмотреть краткое описание выполненных действий и их обоснование, ссылку на тикет задачи, а также план тестирования для проверки правильности изменений.
3. Запустите код — в 90% случаев недостаточно просто посмотреть на код, чтобы найти ошибки. Проблемы обнаруживаются только при запуске и просмотре логов. В некоторых случаях для запуска кода может потребоваться особая конфигурация, подготовка которой должна быть частью процесса код-ревью.
4. Рефакторинг VS поддержка кода — баланс выбора между двумя процессами тонкий: во время ревью нужно подумать, в каких случаях разработчику нужно написать избыточный код или же провести рефакторинг. Здесь нет единственного верного ответа, на выбор будут влиять факторы: наличие времени у разработчика, возможность использования кода в других целях и вероятность регрессии. Оба процесса должны упростить ревью и улучшить код.
5. Сначала логика, потом синтаксис — комментарии код-ревью относятся к двум параметрам кода: стиль плюс синтаксис и реализованная логика. Важно найти баланс, чтобы одно не перевесило другое. В код-ревью предпочтительнее комментировать логику, а если хочется прокомментировать синтаксис, лучше ссылаться на документацию, определяющую стиль кода в команде или поднять эти вопросы на встречах разработчиков.
6. Читаемость важнее производительности — сверхпроизводительный код не всегда понятен другим разработчикам, плохо поддаётся переделке и ведёт к багам при рефакторинге, поэтому лучше написать расширенный код, который будет проще понять и исправить. Другой выход — дать поясняющий комментарий, если есть основания полагать, что он поможет понять замысел автора кода.
Несколько советов
Во время ревью важно оценивать, насколько комментарии улучшают состояние кода, эффективность и работоспособность систем. Комментируйте код строго в контексте улучшения работоспособности системы или её части. Можно дать примеры хорошей реализации и ссылки на паттерны.
Если ваши ревью объёмны и занимают много времени, предложите авторам кода делать изменения небольшими кусочками и создавать пул-реквесты по мере выполнения задач. Дозированную информацию проще ревьюрить.
Подытожим
Оптимизация код-ревью превращает утомительный процесс в эффективный инструмент, который развивает навыки и улучшает качество общения с членами команды.
Рекомендации и перечисленные практики из статьи рекомендуется использовать совместно и по отдельности. Методы помогут оптимизировать процесс и перебороть неприязнь к процессу.
Во время ревью просмотрите каждую строку кода и контекст, убедитесь, что вы улучшаете качество кода, не забудьте похвалить разработчиков за хорошую работу — это делает рабочую атмосферу благоприятной.
Если вы тоже хотите поделиться фишками проведения код-ревью, что-то посоветовать или рассказать историю из опыта — пишите в комментариях.