В процессе разработки качество кода напрямую влияет на успех проекта, и code review — ключевой процесс для его повышения. Эффективно организованный код-ревью может значительно облегчить жизнь команде разработки и тимлидам, при условии, что его проводит подготовленный специалист.
Что делать, если вы хотите внедрить code review на проект, но не знаете, с чего начать или у вас уже был неудачный опыт? Важно понимать, как этот процесс влияет на работу команды. Проблемы могут возникать из-за отсутствия структуры или недопонимания самой цели. Если качество кода в вашей команде не является приоритетом, то и проведение код-ревью не принесет никаких результатов. Код-ревью — это не просто проверка ошибок, а инструмент, который помогает улучшить качество кода, ускорить обучение и наладить общение внутри команды. Чтобы успешно внедрить code review, необходимо подробно разобраться в каждом этапе и учесть типичные ошибки.
Что такое Code Review?
Code review (код-ревью) — это процесс проверки чужого кода членом команды или с использованием автоматизированных инструментов. Сам термин переводится с английского как «проверка кода». Это важный этап цикла разработки, который позволяет выявить ошибки, улучшить архитектуру и структуру кода, а также повысить общий уровень его качества.
Зачем включать код-ревью в цикл разработки?
Давайте разберемся, зачем на проекте нужен код-ревью. Есть несколько основных целей проведения CR: необходимость в улучшении качества кода, стандартизация и обучение других членов команды. Поговорим о каждой цели подробнее:
- Улучшение качества кода
Высокое качество кода подразумевает его читаемость, надежность и производительность, а также упрощает поддержку. Хорошо структурированный код легче понимать другим разработчикам и ресурсы он использует эффективнее. Улучшение качества кода снижает технический долг, а это ускоряет долгосрочную разработку. Кроме того, код-ревью позволяет выявлять ошибки и недочеты до того, как код попадет в основную ветку. Например, если разработчик использует устаревшую функцию, проверяющий может указать на более современный аналог. Кажется, что это мелочь, но в контексте проекта, это может спасти много вашего времени и финансов. - Обнаружение ошибок на ранних этапах
Регулярное ревью помогает выявить баги и потенциальные проблемы до того, как код попадёт в прод. - Стандартизация кода
Код-ревью способствует установлению единых стандартов кодирования в команде. Это особенно важно, когда в проекте участвуют разработчики с разным опытом. К примеру, при ревью можно убедиться, что все следуют одинаковым правилам именования переменных и структурирования кода. - Снижение технического долга
Регулярные ревью позволяют поддерживать код в чистом состоянии, предотвращая накопление долгов. Если разработчики видят, что неэффективные конструкции или нарушения стиля обсуждаются и исправляются, они будут более внимательны к качеству своего кода. - Обучение сотрудников
Команда может учиться друг у друга, перенимая практики и идеи. Это повышает общий уровень экспертизы. Когда сеньор объясняет, почему он выбрал один подход вместо другого, это помогает всем в команде – как минимум, развивать свой подход к разработке. - Улучшение архитектуры
Во время ревью часто обсуждаются вопросы производительности и масштабируемости, что позволяет найти более устойчивые архитектурные решения. - Понимание и комфортная работа в команде
Все понимают логику изменений и участвуют в улучшении проекта, что приводит к более сплоченной и продуктивной работе. Когда процесс проверки настроен максимально прозрачно, в команде не возникает обид и недовольств. Всё работает на общее благо продукта.
Как организовать эффективный процесс code review?
Начать стоит с выбора: как именно вы хотите проводить проверку? Код-ревью может быть ручным или с использованием автоматизированных инструментов, таких как линтеры или системы контроля версий (GitHub, GitLab). В идеале стоит комбинировать оба подхода.
Что такое линтер?
Линтер — это инструмент для анализа кода, который помогает разработчикам находить и устранять ошибки или нарушения стиля. Линтеры проверяют код на соответствие определенным правилам и стандартам, что позволяет поддерживать единый стиль кодирования в команде. Для каждого языка программирования – свой линтер, поскольку он учитывает синтаксис и особенности языка. К примеру, для JavaScript и TypeScript есть ESLint, а код на Python проверяет Pylint. Есть еще SonarLint, который подходит для разных языков и и интегрируется с IDE для проверки кода в реальном времени.
Кто участвует в процессе проверки?
Как правило, это разработчик, создающий код, и один или несколько его коллег, которые проверяют код. Важна также роль тимлида или менеджера, который контролирует качество итогового ревью и его объективность.
Процесс code review
Первый этап: Подготовка
Разработчик проверяет свой код на наличие ошибок и несоответствий, а затем создает pull request (PR). В PR он должен объяснить изменения, цели и контекст кода, чтобы проверяющим было проще разобраться.
Что такое Pull Request?
Pull request (PR) — это запрос на слияние изменений в коде с основной веткой проекта. Он позволяет другим участникам команды просмотреть, обсудить и проверить код перед его интеграцией.
Второй этап: Ревью
Коллеги проверяют код, изучают его логику, структуру и дают комментарии (обычно в самом PR).
Третий этап: Исправление
Разработчик учитывает комментарии и замечания, вносит необходимые правки в код и обновляет PR. Кстати, правки не всегда означают исправление ошибок, иногда просят поработать над улучшением читаемости или производительности кода.
Четвертый этап: Заключение
Если все устраивает, код принимается и интегрируется в основную ветку проекта. Это завершает процесс код-ревью, и разработчик может быть уверен, что его код соответствует стандартам качества команды.
Интервью с DevOps-инженером
Используешь ли ты код-ревью в работе? На постоянной основе или каким образом это происходит?
Стоит отметить, что у код-ревью есть несколько смыслов. Первое код-ревью – это когда ты сам, в процессе разработки, проверяешь код на ошибки, код стайлинг или уязвимости, а затем уже по нему проходятся свежим взглядом твои коллеги. Второе код-ревью, когда, сделав задачу (не всегда это что-то связанное с кодингом), нужно получить апрув по качеству от коллег с грейдом повыше или тимлида. Только после подтверждения ты можешь закрыть задачу. В данном случае, код-ревью — это, получается, стадия бизнес-процесса.
В команде мы используем код-ревью постоянно. Если у кого-то из DevOps’ов задача, связана с написанием или доработкой кода (скриптов, пайплайна, плейбуков и прочего), то действуем по алгоритму:
— Сначала человек пилит функционал согласно всем ТЗ, прописанным в задаче.
— Затем, исполняющий ставит встречу с коллегами. На встрече мы построчно пробегаемся по коду, обсуждаем основную логику и обработку исключений, можем затронуть код стайл (наименование переменных и функций), также смотрим соблюдение принципов ООП и ПОП (объектно-ориентированное программирование и процедурно-ориентированное программирование). В общем, набрасываем все правки и пожелания.
— Далее, ответственный за эту задачу коллега всё допиливает.
— По готовности, двигает задачу в трекере по статусу (из «В работе» в «Код ревью»), добавляя ссылки на выполненную работу и указывая тимлида или коллегу, который будет проводить финальное код-ревью. Если у проводящего есть замечания, то он возвращает задачу в статус «Доработка» и оставляет замечания либо в комментариях к задаче в трекере, либо в мёрж/пулл реквесте в репозитории или в личку исполнителю. И так по новой. Когда замечаний не будет, проверяющий переводит задачу в статус «Закрыто».
В целом, встреч по оценке кода или функционала в моей команде много, так как очень много скриптов и идей их модификаций. Хочется всё реализовать и, самое главное, максимально безболезненно для разработки продукта *улыбается*.
Если я получаю задачу не связанную с кодингом, например, создание базы данных, поднятия сервиса, разворачивания окружения и прочего, то после выполнения задачи двигаются статусы, прикладываются ссылочки и прочие артефакты, которые показывают выполнение задачи, и код ревьюер смотрит корректность выполнения задачи по ТЗ, если всё хорошо — закрывает.
Проверка кода — а зачем она DevOps инженеру? Есть ли особенности code review у DevOps команд?
Вообще, девопсы тоже достаточно кодят: скрипты, пайплайны, плейбуки, докерфайлы, монифесты для кубернетиса и прочее. И всё это нужно ревьюить, чтобы избежать неприятных ситуаций: таймаутов, некорректного поведения, уязвимости в безопасности, использования лишних серверных и временных ресурсов и прочего.
Ещё, стоить отметить, что ошибка в коде девопса в отличие от кода разработчика, зачастую будет иметь более глобальные последствия. Одно дело, когда у тебя 1 из 100 микросервисов некорректно функционал работает, а другое, когда твой код убил на проде 100 микросервисов и вообще серваки лежат и никто работать не может.
Возможно у тебя есть опыт, когда ты была в роли человека, над которым проводили код-ревью. Опиши, как ты тогда к этому относилась, какие-то позитивные и негативные моменты.
Я всегда с позитивом отношусь к код-ревью, если это, конечно, не горящий дедлайн и 100500 правок и столько же конфликтов в гите, *смеется*.
У нас в команде каждый понимает, что любое выявление ошибок позволит в будущем избежать большего количества головной боли, стресса и негатива из-за того, что всё перестало работать или работает как-то не так.
Да, иногда, по несколько раз приходится переписывать код, доводить до совершенства, это утомляет, ты бубнишь под нос «Да я не разраб, шоб всё по паттернам делать», но потом понимаешь, что лучше так, чем отвечать одновременно большому количеству злых разрабов, у которых перестал деплоиться сервис или ещё что-нибудь в жизни плохое случилось.
Как ты сама относишься к код-ревью? Нужен/не нужен? Актуально ли это сейчас, в 2024, на проектах? Если да, то на каких?
Код ревью нужен! Проекты становятся масштабнее, обрастают кодом, который помогает автоматизировать процессы и любая ошибка в этом коде может привести к отказу всего продукта, над которым работала твоя команда. И не важно, маленькая команда из 5 человек или 5 тысяч – всё это человеческий труд и время, которые нужно ценить.
Есть ли у тебя какой-то топ или ситуация (история) о конкретных проблемах, которые помог решить/предотвратить своевременный код ревью?
Первое, думаю, его отметит каждый девопс, код ревью пайплайнов. Помимо того, что код-ревью здесь помогает избежать каких-то проблем со сборкой/тестированием/деплоем сервисов, он же ещё и помогает сократить время выполнения этих процессов. И вот тебе уже не нужно ждать по часу пока развернется окружение, всё будет сделано за 15 минут, *улыбается*.
Code review манифестов позволяет скорректировать работу сервисов в кубернетисе, особенно отследить потребляемые ресурсы (реквесты и лимиты), а также различные пробы для под (ливнес, риднес, старт).
Второе, скрипты. Скрипты бывают самые разные, но в основном они нужны для того, чтобы облегчить жизнь девопсов, который устал делать одни и те же действия, чтобы всё корректно работало, да и так шанс ошибится сразу меньше становится. Написал скрипт — отдебажил, закодревьюил и всё пользуйся со 100% уверенностью, что скрипт не сделает лишние действие, нигде не создаст и не удалит чего-нибудь важного.
Код-ревью докер файлов -позволяет увидеть и устранить уязвимости, уменьшить вес образа.
Код-ревью плейбуков — это аналогия со скриптами, только ещё возможность гибко настроить скрипты под разные операционные системы.
Типичные ошибки, которых следует избегать в процессе ревью
- Микроменеджмент – убийца креатива
Переизбыточный контроль может подавлять инициативу, креативность и как следствие, мотивацию. Лучше дать разработчикам возможность находить решения, а не диктовать каждую деталь. Учитесь соблюдать баланс между кодом по стандарту и креативными идеями команды. - Отсутствие общих требований к коду
Без ясных стандартов оценка качества кода может быстро обрасти недопониманиями и предвзятым отношением. Это приводит к путанице и различным ожиданиям между участниками ревью. Важно установить критерии, чтобы все понимали, на что обращать внимание. - Переход на личности
Оценка кода должна быть конструктивной. Если комментарии касаются личности разработчика, это может вызвать напряжение и конфликты. Используйте нейтральный язык и обсуждайте только код. - Игнорирование комментариев
Все замечания должны быть учтены и обсуждены. Если разработчик не реагирует на комментарии, это может указывать на его недостаточно развитые soft skills.
Как давать конструктивную обратную связь?
- Использовать «я-сообщения»: Формулируйте свои комментарии так, чтобы они начинались с «я», а не “ты или у тебя”, например: «Я заметил, что…». Так вы сможете избежать обвинительного тона.
- Быть конкретным: Указывайте на конкретные проблемы. Старайтесь оценивать код объективно, не используя подход “на его месте я бы..”.
- Соблюдать баланс: Сочетать критику с похвалой. Не стоит выкатывать целый список ошибок с комментарием “в целом все неплохо”. Старайтесь балансировать и подмечать хорошие решения своих коллег.
- Предлагать альтернативы: Критикуешь? Предлагай! Но не перебарщивай. Вместо того чтобы просто указывать на ошибки, предлагайте альтернативные решения или лучшие подходы, чтобы разработчик мог учиться.
- Давать время на ответ: Позвольте разработчику обдумать ваши комментарии и задать вопросы, если что-то неясно. Это помогает избавиться от ощущения “сверхконтроля”. Главное, чтобы свободное время для размышлений не перерастало в ошибку под номером 4.
Code review — это больше, чем проверка кода
Code review — это не просто техническая проверка. Это способ улучшить культуру разработки внутри команды. Он помогает наладить тесное взаимодействие между разработчиками, стимулирует обмен знаниями и опытом, создает здоровую среду для обсуждения технических решений и улучшает навыки.
В такой атмосфере ошибки рассматриваются как шаги к обучению, а не как неудачи. При правильной реализации, внедрение code review в конечном итоге приведет вас к более качественному продукту и довольным клиентам!