На этом моменте может возникнуть вопрос. А зачем тогда тестирование и автотесты? Если забегать вперёд, то на самом деле код-ревью используется не только для того, чтобы выявить явные синтаксические ошибки. С поиском явных ошибок спокойно и автотесты справляются и мы даже сделали про них отдельный видос.

У код-ревью цели поинтереснее. Для начала давай определимся. Код-ревью это процесс при котором разработчики, проверяют код своих коллег на качество и понятность. Чаще всего разработчики побольше проверяют коллег поменьше.

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

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

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

Кстати, существуют специальные программы, которые форматируют и подгоняют написанный код под принятые в команде стандарты. Их называют форматировщики и линтеры. Что первые, что вторые часто дополнительно загружаются в проект. Например, в Python есть форматировщики black и yapff, которые могут буквально одной командой подогнать все файлы проекта под единую структуру. А в JavaScript есть очень мощный форматировщик и одновременно линтер – ESLint, который называется в честь стандарта написания кода на этом языке. При встраивании в редактор он может в реальном времени при сохранении файла улучшать его структуру.

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

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

Начнём с того, что весь этот процесс сейчас такой простой и возможен благодаря специальным сервисам для хранения всех изменений происходящих в коде. Да, сейчас мы про системы контроля версий и специальные сайты, где хранится исходный код программ.

Сначала разработчик решает какую-нибудь рабочую задачу, пилит фичи, правит баги и потом сохраняет сделанные изменения - делает так называемый commit. Это когда фиксируются именно сделанные изменения относительно предыдущих. Все изменения сохраняются в репозиторий. Причём, там сохраняются не только изменения, но и то, кто их сделал и когда их сделал. Работает это чаще всего с помощью популярной системы контроля версий Git.

После фиксирования сделанных изменений ими нужно поделиться с другими членами команды и в целом сохранить написанный код в каком-то месте, которое отовсюду доступно. Просто локально на нашем компухтере код доступен только нам и агенту ФБР.

Для этого как раз используются сервисы для удалённого хранения репозиториев. Самые популярные это GitHub, GitLab или BitBucket. Причём, GitHub это ещё и целая социальная сеть для программистов, а GitLab это прям мощный корпоративный комбайн для работы с кодом.

Вот как раз значительное удобство в этом процессе делают именно эти сервисы. Написанный код не сразу попадает в общую кучку кода. Сначала создается Pull request, он же запрос на внесение изменений. Где-то он называется Merge request.

В нем видны все изменения в коде, что добавилось (зеленое), что удалилось (красное), и дополнительно разработчик описывает то, что он там понаписал.

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

В первую очередь проверяется то, насколько грамотно написан код. То насколько всё логично, понятно эффективно.

Потом код проверяется на всякие ошибки. Синтаксические, логические, архитектурные, стилистические.

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

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

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

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

Окей, немного отвлеклись, давай продолжим. Так вот, ревьювер либо в итоге пропускает твой код дальше и он вставляется в общий код, либо отправляет код тебе на доработку вместе с вопросами и исправлениями.

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

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

Если ранее никогда в этом процессе не участвовал, то давай мы дадим тебе горсточку советов, которые помогут быстренько его пройти.

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

Ещё обязательно отвечай на комменты ревьювера и учись на допущенных ошибках, чтобы потом код-ревью проходил быстрее. Задавай вопросы и будь вежлив, ведь, у ревьювера нет цели тебя закибербуллить. Вы в одной лодке. 

А когда готовишь пулл реквесты, старайся разбивать их на части. Чем меньше изменений в PR – тем проще его проверять.

Ну, а когда сам будешь ревьюить код, помни что нужно обсуждать, а не критиковать. Не надо просто говорить «здесь плохо» – лучше предложить альтернативу или спросить, почему так было сделано.

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

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