Egor Levchenko

Заметка

6 причин, почему вам не стоит идти в код-ревьюеры

Каждый из разработчиков хоть раз в жизни сталкивался с проверкой своего кода. Это мог быть быстрый просмотр работы кем-то из коллег, к которым вы обратились с вопросом или проблемой. Мог быть разбор задачи со стороны начальства перед выпуском работы в production. Даже вы сами могли отложить работу, а потом окинуть ее свежим взглядом через некоторое время. А иногда это было полноценное код-ревью специалиста, который проверит код по строгим параметрам: от банальной работоспособности до стандартов, описанных в Style Guide компании.

Впервые я столкнулся с настоящим код-ревью, когда проходил обучение в Яндекс.Практикуме. Если честно, вначале я не верил, что все работы проверяются живым человеком, и, тем не менее, всё именно так. Через какое-то время я подумал: а круто было бы самому стать ревьюером и помогать студентам с кодом...

Да, круто, но далеко не для всех. Я прошел тестовое задание, начал работать, набил шишки и сейчас делюсь почему вам не стоит становиться ревьюером кода.

Мои 6 причин, в которых я ни слова ни скажу про внутреннюю кухню своего работодателя.

Это не та творческая работа, что вы ищете 🔗

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

Код-ревьюер — не музыкант. Он — дирижёр.

Даже если вы видите очевидное решение, вы не можете, как говорили большинство учителей в школе: «приставить свою голову»вы должны сделать всё, чтобы автор кода не просто самостоятельно пришёл к нужному решению, но и понял, почему такое решение является правильным.

С каждой итерацией вам нужно направлять человека, давать необходимые источники, чтобы в конце-концов сказать: «Ты молодец! Так держать!»

И тут мы переходим к следующей причине:

Код пишет человек 🔗

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

Когда вы создаёте веб-сайт, у вас есть миллион и один способ решить задачу бизнеса. Даже, если ваш работодатель работает с чётким списком технологий и имеет чёткие инструкции по стилям, для решения тривиальной задачи можно выбрать разные пути. Нравится вам Grid, а не Flex? Можете закрыть разницу в поддержке браузерами любимым костылём? Отлично. А что, если код-ревьюер на дух не переносит иного мнения?

Людям, которые не терпят альтернативных решений, не место в команде ревьюеров.

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

Важно понимать: ревьюер — это не полицейский с палкой, который будет очень недоволен, если увидит некачественный код.

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

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

Правила, много правил 🔗

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

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

Помните «несправедливость» в школе, когда кому-то из одноклассников ставили оценку выше, а другому её занижали? (Если нет, то у вас были идеальные учителя.) Код-ревьюер не должен ставить кого-то из авторов в больший приоритет. Все равны, а код-ревьюер просто не имеет морального права на ошибку.

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

Например, «мейнтейнеры» кода вывели новую технологию, а команда ревью ещё не приняла решение: считается такой вариант корректным и протестированным, или пока нет.

Разработчик использовал новый вариант и отправил работу на проверку.

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

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

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

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

Работы будет много, очень много 🔗

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

Я уже сравнивал эту работу с трудом учителя. Могу сказать профессионально (высшее образование получал как преподаватель иностранных языков): у современных учителей работа не ограничивается парой часов, проведённой с учениками. Большая часть работы — проверка домашних заданий, и это может забирать 8-12 часов чистого времени.

Код-ревьюер не ведёт лекции и семинары, он только проверяет «домашние работы». Множество работ.

Скажете: «Так именно за это ему и платят!» — и окажетесь не совсем правы. Код-ревьюер получает свои деньги за результат, которого добились авторы, и который ушёл в production. То, что мотивация может зависеть от количества работ, итераций или времени — это попытка менеджеров, которые редко когда писали код сами, оценить труд своего сотрудника.

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

Большие проблемы код-ревьюеров: рутина и время.

Если вы долго работаете над одним куском кода, ваш взгляд рано или поздно «замылится». Кстати, и для этого тоже нужны ревьюеры — обращать внимание автора на упущенные моменты.

Я уже писал, что это не то творчество, когда результат зависит только от вас. А если автор присылает новую итерацию уже в третий раз? А если он такой не один? А если вы только сейчас заметили, что что-то упустили в прошлый раз?

Общение с людьми 🔗

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

Код-ревьюер — это всегда работа с людьми.

Да, в большинстве современных IT-компаний (особенно в режиме «самоизоляции») разработчики и ревьюеры сидят дома, а иногда и живут в разных частях страны, а то и в соседних государствах.

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

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

Это часть работы, и от этого никуда не деться.

Опыт, достаточный опыт 🔗

И тут мы подошли к финальному пункту: код-ревьюер должен обладать достаточным опытом разработки.

Достаточным — это не просто большим.

Например: «Я делаю landing pages уже 3 года, могу я быть отличным код-ревьюером в команде frontend-разработки?» — нет, если ваши страницы вы делали на Tilda, а вся работа заключалась в выборе шаблона из списка, и добавления текста, присланного заказчиком.

Код-ревьюер обязан разбираться в той технологии, с которой он работает.

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

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

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

Тут я должен ответить на вопрос: «Всегда ли код-ревьюер должен выступать в роли ментора для разработчика? Или это особенность Яндекс.Практикума, как площадки для обучения новых специалистов».

Во-первых, знать абсолютно всё невозможно, а потому быть разработчиком значит учиться на протяжении всей своей карьеры. Часто случается так, что долго работая над одним (не обязательно даже legacy-) продуктом, специалист замыкается в технологии. Он видит проторенные решения, и следует им на автомате. При этом языки программирования не стоят на месте, и там, где раньше изобретали велосипед, сейчас работает framework. Стоит ли об этом написать автору кода? Да! Ведь это сэкономит время и разработки, и проверки, а ещё деньги на выпуск проекта конечному пользователю.

Во-вторых, и это тоже важная причина: вакансий для разработчиков больше, чем специалистов, которые готовы на них откликнуться. Это значит, что многие компании готовы принимать на работу «джунов», которые ещё не знакомы с более узким «стэком» в компании. Нужно ли их доучивать? Да! И лучше всего делать это без отрыва от процесса разработки.

Ну и, наконец, в-третьих, код-ревьюер не просто «подгоняет» работы специалистов под некий, принятый в компании Code Style Guide. Если разработчик не привык ставить так необходимые всем точки с запятой в конце каждой строки в JavaScript, ему поможет Pretier, но если он не может писать код по принятым стандартам (например ООП) — работа код-ревьюера донести необходимость их соблюдать.

Вместо заключения 🔗

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

Во-первых, в команде с ревьюером вы гарантированно получите поддерживаемый код. Через полгода или год, когда вы забудете, что хотели сказать тем или иным выражением (а может и не вы вовсе делали тот самый коммит), вы легко вернётесь к задаче.

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

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

При этом я убеждён, что эта работа подходит далеко не для всех.

Не все игроки в футбол или баскетбол становятся классными тренерами. Но при этом они могут стать отличными игроками.

Если вы уверены в своих силах, вам стоит попробовать.

Если вам понравится, значит это ваше. Останется только совершенствоваться, потому что разработчик учится всю свою карьеру. А прочитать про код-ревьюеров конкретно в Яндексе можно в статье на Яндекс.Академии.