#вопросы #frontend #развитие

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

—————————————————————————-
💲 Напоминаю, что рубрика вопросов, все еще актуальна. В будущем я буду отвечать постом + записывать short видео. Вы также можете задать любой вопрос.
—————————————————————————-

Как я провожу ревью на проекте, как техлид и как проводил раньше? Читаю ли описание задачи в таск-трекере? Проверяю реализации в ветке? Насколько глубокий анализ?

Начнем по-порядку, ревью на проекте, так как не было уточнений, предположим, что это ревью конкретной таски, когда на вас падает MR (merge request) .

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

#️⃣Процесс ревью:

Мы работаем полностью в гитлабе, и как таск-трекер и как система поставки / версионирования. Я читаю прилинкованную задачу, только при необходимости. Если из заголовка непонятно, что было в разработке. Обычно я уже в контексте, и знаю над чем работал разработчик. Далее я прохожу по коду, смотрю нейминг, реализации. Вопросы возникают, если переменную назовут a,b,c, либо реализация большая сложная, а можно было сделать проще и я это вижу с ходу. Тогда я оставляю комментарии.

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

Вся переписка ведется в тредах MR, и там же резолвится.

❓ А у вас есть, правила специфичные для процесса код-ревью?

P.S. Если вы не согласны, или у вас есть свое мнение, прошу в комментарии там все обсудим.