Введение
В мире разработки ПО, code review является неотъемлемым процессом обеспечения качества кода. Несмотря на то, что во многих организациях ревью кода проводятся несистематически и чаще всего в критические моменты или при необходимости значительных обновлений, важность установления регулярности и формализации этого процесса неоспорима.
Ниже я привожу рекомендации, которые во многом позволили мне взгянуть на этот процесс под немного другим углом. Надеюсь, они помогут некоторым поменять свое отношение к ревью кода, и вы будете относиться к нему не как к достаждающей обязанности, но как к процессу, который не только делает ваш код лучше, но и позволяет делиться опытом между разработчиками и cделать вашу команду более сплоченной.
1. Время и объем кода для ревью
Идеально ревьюировать от 200 до 400 строк кода за одну сессию и при этом стремиться к темпу проверки 300-500 строк кода в час. Такой подход подчеркивает важность равномерного и вдумчивого подхода к каждой строке кода, без пропуска, казалось бы, незначительных участков. При соблюдении таких рекомендаций, одна сессия займет как раз около часа, или чуть болше, если вам требуется время на дополнительные обсуждения. Этот подход позволяет достаточно глубоко погрузиться в детали без потери концентрации и внимания участников ревью. При большей продолжительности по времени эффективность значительно снижается из-за усталости участников. Такие правила помогает сохранить внимание и концентрацию на высоком уровне, и при этом не отнимут у коллег слишком много времени в течении рабочего дня, что будет воспринято ими положительно.
2. Подготовка и оценка эффективности ревью
Важно, чтобы автор кода активно готовил свой код к ревью, включая адекватное комментирование и документирование. Неожиданный совет, о которм я не знал раньше: можно ввести специальные комментарии, которые помогут обратить внимание на конкретные участки кода при проведении code review. Это не только упрощает понимание кода для рецензентов, но и помогает автору пересмотреть и возможно улучшить свой код ещё до начала ревью.
Установление конкретных, количественно измеримых целей для каждой сессии ревью и последующая фиксация достигнутых метрик может значительно улучшить как качество самого кода, так и процесс ревью в целом. Это может включать, например, количество исправленных багов, улучшение производительности кода или повышение его читаемости. Главное, чтобы эти параметр были оценены объективно (количественно, процентно, и т.д.) тогда команда может наглядно увидель результат своей работы.
Чек-листы могут стать отличным инструментом как для авторов кода, так и для рецензентов. Они помогают не пропустить важные аспекты в процессе ревью, такие как соответствие стандартам кодирования, отсутствие ошибок, которые может выявить линтер, правильное использование форматирования и наличие необходимой документации. Создание и соблюдение общих чек-листов может значительно повысить качество и эффективность ревью. Главное, не делать огромные чек листы, заполнение которых будет занимать всё время, достаточно десятка пунктов, которые будут выступать как опорная информация при проведении ревью.
Ещё одна из ключевых задач code review — убедиться, что все обнаруженные дефекты были действительно исправлены, что, как ни странно, бывает легко упустить, особенно если вы не проводите формальную оценку проведения ревью. Использование систем отслеживания дефектов и тестирование могут помочь в этом, обеспечивая дополнительный уровень проверки.
3. Культура проведения ревью
Формирование здоровой культуры обзоров кода является, возможно, самым сложным аспектом. Важно стремиться к тому, чтобы обратная связь воспринималась как возможность для учебы и роста, а не как личная критика. Создание атмосферы взаимопонимания и поддержки в команде может превратить code review в продуктивный и даже желанный процесс.
Важно подходить к процессу обзора так, чтобы избежать ощущения постоянного контроля. Подчеркивание того, что цель обзора — улучшение качества продукта и поддержка развития навыков, поможет смягчить возможное негативное восприятие.
При этом при отсуствии токсичности в команде, этот процесс можно превратить в соревнование (дружелюбное :)) за качество кода. Важно, чтобы разработчики воспринимали обзор как возможность для обучения и совершенствования, а не как угрозу.
4. Полезность легких обзоров
Последний пункт самый небольшой, но, возможно, самый важный. Необходимо постоянство при проведении code review. При этом известно, что даже короткие, но регулярные сессии дают практически все преимущества, которые можно получить от этой практики: улучшение качества кода, обучение разработчиков, обмен идеями и повышение сплоченности команды.
Выводы
Множество рекомендаций, представленных в этом обсуждении, предполагают более структурированный и формализованный подход, чем тот, с которым часто сталкиваются команды разработчиков на практике. Не редкость, что даже при внедрении таких практик они не удерживаются на долгий срок. В то же время, многие из этих подходов являются интуитивно понятными и естественными для большинства разработчиков, такие как ограничение времени на ревью, размеренный темп, и восприятие ошибок как возможностей для роста, а не повода для критики. Эти принципы не требуют особых объяснений. Для улучшения культуры code review важно сочетать это понимание с дисциплиной, последовательностью и формализованным подходом, включая отслеживание метрик. Внедрение этих правил зависит не только от усилий отдельных лиц, но и от поддержки со стороны команды, менеджмент и общей корпоративной политики. Хотя не всегда возможно достичь идеального сценария ревью, стоит приложить личные усилия для движения в этом направлении. Даже если вы внедрите хотя бы некоторые из этих рекомендаций, они могут помочь вам в работе разработчика.