5 из 7: Как вы проводите кодревью (как узнаете, делаете сразу или откладываете на вечер, как взаимодействуете с коммиттером, ваши лайфхаки и подходы).

Зависит от срочности, обычно стараюсь отложить на конец рабочего дня

1. узнаю в ММ канале merge_requests 2. ASAP делаю ревью 3. как сделал ставлю лайк сообщению в ММ канале 4. если получаю от автора замечания или сообщение что все исправил смотрю и если ок ставлю лайк и сообщаю автору (сам не мониторю статус МР что исправлено) 5. если код очень непонятный или из другого проекта то не погружаюсь в процесс и не сильно придираюсь, проверяю формальные признаки - понятный код, стиль 6. проверяю код в гитлабе, не выгружаю себе ветку и не проверяю что работает

День в день. Иначе код без ревью поедет на прод.

as soon as I see it

По обстоятельствам

Когда нет срочных заданий

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

Обычно провожу не сразу. Взаимодействую с коммитером через комментарии к коду в GitLab

При получении оповещения по почте

Откладываю, делаю когда прижмет (попросят)

Если задача не критичная, откладываю на время, когда можно спокойно погрузиться в контекст. Отвожу часть рабочего дня именно под ревью, делаю несколько сразу. По процессу – у нас на доске есть отдельная колонка для тикетов в ревью, но туда не смотрим, разработчик сам тегает в чате ревьюеров, когда готов. Всё взаимодействие - в МР-е в гитлабе, там пишем комментарии. Мелкие изменения типа орфографии сразу предлагаем через специальный интерфейс. Очень редко можем созвониться, чтобы что-то прояснить и даже устроить парное программирование. В 80% случаев в первую очередь смотрю и "тыкаю руками" дев-стенд, проверяю соответствие описанию тикета, а также места, которые могли быть затронуты изменениями (по сути, провожу небольшое ручное тестирование). Затем пробегаю глазами весь реквест - за грубые косяки вроде неубранных комментариев глаз цепляется сразу. Затем внимательнее просматриваю места с алгоритмами, неочевидной/сложной логикой, основную бизнес-логику.

Фиксы - сразу, фичи - долго (бывает и неделю может висеть)

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

Ну все как обычно.

В начале и во второй половине дня

Github notifications, usually within 2 days. In most of the cases, i only leave comments on GitHub without any private communication. Just to keep history

Среди опытных разработчиков из смежных команд договорились о незамедлительном проведении ревью открытых MR-ов, если нет ничего более срочного.

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

Утром смотрю новые PR в VCS

Сразу, по возможности

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

Когда есть передышка, но стараюсь в тот же день. Сначала просто список замечаний (Feedback ladders), если начинается длинная переписка - прошу автора уведомить меня, когда нужно опять читать.

Если небольшой, то сразу. Большие MR откладываю на вечер. Если замечание требует дискуссии, то обычно ставлю замечание и связываюсь с коммитером. Для больших MR часто локально делаю мердж git merge --squash чтобы видеть изменения и удобнее перемещаться по коду в IDE

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

Простые смотрю в течение дня, сложные откладываю на утро или вечер

Ревью планируется по времени. Вся переписка ведется только в комментариях\тредах в MR, если было какое-то устное обсуждение, то оно обязательно тезисно фиксируется в комментариях в MR. Если в ходе какого-либо обсуждения(треда) в MR было решено оставить в коде TODO, то TODO обязательно содержит в теле ссылку на этот тред. MR обязательное должен содержать описание. MR желательно должен быть разбит логически на патчи по коммитам. Очень большой MR желательно разбить на несколько MR. Обязательно обращать внимание на code coverage для кода в MR.

Всегда по утрам

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

Выделяю часть рабочего времени каждый день.

На собрании в соответствие с указанными сроками. Результаты отображаются в IDE и соответствующих сопроводительных документах.

6 из 7: Ваши предложения по улучшению кодревью?

Проводить качественный селф тест перед отправкой на МР

1. дать на аутсорс кодревью (Code Review as a Service https://www.pullrequest.com/) 2. балансировщик ревью чтобы в среднем все по объёму делали одинаковую работу 3. назначать по матрице кому что ревьюить - люди по отделам, бэкеры бэк, фронты фронт 4. обязательный ревьюер один из проекта и необязательные ревьюеры из других проектов, просто шаринг знаний и экспертизы 5. написать чеклисты для ревью для кода C#, Angular 6. попросить всех делать ревью МР ASAP

Не делать большие PR. Если ревью занимает часы, то лучше просто парно попрограммировать. Не токсичить Сложные задачи и их решения предварительно оговаривать в виде ADR/RFC/Proposal. Фича на проде сегодня важнее красивого кода завтра.

Маленькие MR.

Самому бы получить пару советов :)

Делайте круговое код ревью. Пара глаз хорошо, а несколько - лучше

Чтоб были тесты доказывающие работоспособность, или видео

Чем больше всякого вроде линтеров, статического анализа, тестов, тем больше на ревью удастся уделять внимание бизнес-логике и архитектуре. Еще удобно договориться об общем "языке" и в целом о процессе: например, префикс nitpick делает комментарий необязательным к исполнению; крупные изменения по стилю/рефакторинг можно выносить в отдельный тикет в техдолг, чтобы не задерживать разработку, и т.д.

Стоит проводить их в комфортной обстановке

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

Маленькие итеративные MR-ы, чем один большой.

Чтобы джуны хотя бы иногда делали ревью коллег, что выше по опыту

Все норм

Хороший style guide, монорепозиторий (позволяет искать и читать много кода разных команд, изучать лучшие практики), наличие тестов

Автоматизация базовый вещей (форматтеры, линтеры, статические анализаторы, тесты, визуализация тестового покрытия и пр), их интеграция в процесс через CI.