Remote и асинхронный review

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

В одном офисе неясность в PR стоит вопроса через стол — минута. При разнице в семь часов вопрос заданный в 18:00 получит ответ в 11:00 следующего дня, и то если адресат начинает день с ревью.

Отсюда вся стратегия: каждый раунд должен закрывать максимум неясности. Это меняет то, как пишутся и описания PR, и замечания.

Практические следствия:

Последний приём недооценён. В распределённой команде повторное ревью мелких правок — чистая потеря суток. Доверие к автору в мелочах дешевле, чем ещё один цикл.

Проверьте себя. Посчитайте пересечение рабочего дня между самыми удалёнными участниками команды. Сколько часов?

Частая ошибка. Оставлять замечания порциями, по мере чтения. В асинхронной команде это самая дорогая привычка.

В офисе описание можно недоделать — спросят. В распределённой команде описание PR — единственный носитель контекста.

Что должно быть, чтобы ревьюер не задавал вопросов:

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

Проверьте себя. Откройте свой последний PR и допишите раздел «альтернативы». Сколько вариантов вы обдумали и никому не сообщили?

Частая ошибка. Считать, что описание нужно ревьюеру. Оно нужно и вам через год, когда git blame приведёт сюда.

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

Признаки, по которым надо остановиться:

Обязательное условие: результат синхронного разговора фиксируется в PR. Иначе через год решение выглядит немотивированным, а для остальной команды оно вообще не существовало.

Три строки, снимающие вопрос «почему так» навсегда.

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

Проверьте себя. Найдите в репозитории тред длиннее пятнадцати комментариев. Сколько он занял дней и чем закончился?

Частая ошибка. Провести созвон и не записать итог. Решение принято, но для всех, кто не участвовал, его нет.

Для решений, влияющих на систему в целом, отдельного PR недостаточно — его никто не найдёт через год. Работает запись архитектурного решения (ADR): короткий файл в репозитории, один на решение.

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

Хранится рядом с кодом, в docs/adr/. Не в вики: вики не видят при работе с кодом.

Проверьте себя. Назовите три архитектурных решения вашего проекта, причины которых сейчас никто не помнит.

Частая ошибка. Писать ADR на всё. Их пишут для решений, которые дорого отменить, — иначе получается свалка, в которой не найти нужное.

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

Что работает:

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

Проверьте себя. Есть ли в вашем проекте путь, который может ревьюить только один человек? В каком он часовом поясе?

Частая ошибка. Считать SLA в календарных часах. Считать надо в рабочих часах адресата, иначе метрика бессмысленна.

Автор в Тбилиси, ревьюер в Лиссабоне (разница 3 часа), второй ревьюер в Сан-Франциско (разница 11 часов). Изменение — на 120 строк.

Девять дней, восемь раундов, 120 строк кода. Ни одного конфликта, ни одной грубости, все отвечали в течение своего рабочего утра.

Что произошло. Из восьми раундов содержательными были два: порог для крупных сумм (настоящее замечание) и метрика (полезное дополнение). Остальные шесть — выяснение того, что автор уже знал, но не написал.

Раунды 1 и 2 (реплика в ЕС) и раунд 5 (асинхронная проверка) — это отвергнутые альтернативы. Автор их обдумал, обсудил и не записал. Цена — три раунда, то есть примерно четыре дня.

Раунды 3 и 4 (безопасность, порог) — тоже частично следствие описания: автор согласовал решение с безопасностью, но в PR этого нет, и ревьюер прошёл этот путь заново.

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

Ревьюер A выдавал замечания по одному, а не все сразу. В офисе это нормально; при 3-часовой разнице каждый вопрос — полдня.

Что было бы иначе:

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

Чем закончилось в реальности. После разбора команда внесла в шаблон PR раздел «альтернативы, которые я отверг», настроила CODEOWNERS и договорилась о двух правилах: замечания выдаются пакетом, мелкие правки не требуют повторного ревью. Медианное время до мержа упало с шести дней до одного.

Отдельно завели docs/adr/ — по этому же случаю выяснилось, что решение про синхронную проверку антифрода принималось дважды и оба раза заново обсуждалось с юристами.

Как передаются знания, чтобы не оставалось единственного компетентного человека, — Передача знаний. Что делать, когда несогласие не разрешается перепиской, — Разрешение конфликтов. Настройка автоматического назначения — Инструменты и интеграции.