Хабрахабр

Как сократить код-ревью с двух недель до нескольких часов. Опыт команды Яндекс.Маркета

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

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

Для начала надо представить, какой флоу в разработке у нас принят:

То же самое, только по пунктам и словами:

  1. Разработчик берет таску.
  2. Делает ее.
  3. Заливает в Github и открывает PR.
  4. Проходит код-ревью.
  5. Собирает демо-стенд и отдает тестировщику.
  6. Тестировщик проверяет демо-стенд.
  7. Проверенную таску собирают в релиз.
  8. Тестирование в релизе.
  9. Выкладка на прод.
  10. Финальное тестирование на бою.

По зонам ответственности таска делится на следующие шаги:

1-5 — ответственность на разработчике;
6-7 — ответственность на тестировщике;
8-10 — ответственность на релиз-мастере.

Благо есть внутренние инструменты анализа. Итак, начали анализировать, что же занимает у нас больше всего времени. Но один момент нас удивил больше всех. Все делали ставку на то, что дольше всего будет занимать, само собой, сам процесс разработки (статус «В работе»)… и так и оказалось. Средняя продолжительность ревью — две недели!

Действие 1. Разбор PR

Оказалось, что у нас есть огромное кладбище незакрытых пулл-реквестов. Начав изучать пулл-реквесты, сразу же столкнулись с одним очень интересным фактом. Кто никогда не видел динозавров, то вот они: Большинство авторов этих PR уже не работали в компании, но их наследие всё еще было с нами.

Со спокойной душой мы их позакрывали. Эти пулл-реквесты добавляли шум и мешали правильному анализу времени код-ревью. А оно по-прежнему было в районе 2-3 дней. Оставалось только пересчитать время. Нехорошо.

Действие 2. Разборка с ревьюшницей

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

Исследование привело в Github, где у нас заведена отдельная команда ревьюеров. Это не сходилось с нашими показателями: один-два PR в день на человека. С тех пор количество сотрудников увеличилось в два раза, но никто из новичков в команду ревьюеров не входил. Эта команда не обновлялась несколько лет. Исправили это досадное недоразумение. Иначе говоря, половина команды вообще не участвовала в код-ревью!

Действие 3. Расширение инструментов

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

  • кодстайл-чекеры;
  • прогон тестов;
  • различные проверки-нероняйки в самом PR;
  • ревьюшница;
  • оповещения на почту и в таск-трекер.

Бери и ревьюй! Казалось бы, всё есть.

Унифицировали и заодно докинули проставление лейблов для удобного поиска PRов через интерфейс Github. Первое, что оказалось не так: разный процесс код-ревью в разных репозиториях.

Многие, чтобы не отвлекаться от работы, разбирает свою почту несколько раз за день. Второе, что заметили: почта — не лучший инструмент для быстрого информирования о статусе код-ревью. Реакция на сообщения в мессенджерах куда выше. Совсем другое дело мессенджеры. Бот шлёт оповещения о статусе код-ревью как для автора пулл-реквеста, так и призывает людей поревьюить. И было решено подключить бота к нашему мессенджеру. Очень удобно.

Действие 4. Первый SLA

Объясняли, что доведение до «Проверено» — это ответственность разработчика. Параллельно действиям 2 и 3 мы начали плотно работать с сотрудниками и объяснять, что код-ревью неотделим от выполнения самой задачи. Быстрая доставка фичи до прода — вот чего хотелось достичь. Причем ответственность не только перед коллегами, но и перед пользователями! И команда с пониманием отнеслась к процессу улучшения.

Конечно, всем хочется, чтобы оно проходило за 5 минут, но это возможно не всегда. На этом этапе зародилось первое представление об идеальном код-ревью. 24 часа. Взяв в расчет, что у нас мультирегиональная команда (с разницей во времени в четыре часа), мы договорились, что нашим SLA будет один день, т.е. Огласили всем сотрудникам этот SLA и, потирая руки, стали ждать результатов.

В лучшие недели половина пулл-реквестов укладывалось в 1 день. Но ситуация так и не изменилась. Остальные так и вылезали за него.

Им мы и стали грепать на ежедневной основе все PRы в поисках "отстающих". У нас был небольшой скрипт, который оценивал время код-ревью на PR. Почти каждый день находилась пачка таких.

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

Действие 5. Трекер SLA

Наши коллеги из Трекера анонсировали удивительную вещь: теперь можно установить SLA в самом Трекере. Помощь пришла откуда не ждали. Некий таймер включается по какому-то событию в таске. Причем настроить его можно совершенно разнообразно. И по какому-то событию останавливаться. По какому-то событию может вставать на паузу. Да это то, что нам надо!

Настроили, чтобы таймер включался при переходе в статус "Need code review" и завершался при переходе в любой другой статус, кроме "Есть замечания" – при нём таймер вставал на паузу, т.е. Сразу полезли детально изучать документацию (кстати, вот она) и настраивать наши очереди (их несколько, так как несколько репозиториев). не сбрасывал своё время.

Мы выставили, что на код-ревью отводится 9h, т.е. Ещё оказалось классно то, что таймер учитывал рабочее время и календарь! При этом оповещение срабатывает через 2h после старта, или если сорвали девятичасовой срок. один рабочий день. Поначалу мы включили таймер ради эксперимента, собрали пачку багов и отрепортили в Трекер. Получился своеобразный честный мониторинг.

Поэтому мгновенного эффекта увидеть не удалось. Стоит отметить ещё то, что таймер включался только для тасков, которые были созданы уже после внедрения самого таймера. Эффект мы получили уже спустя месяц, когда поток новых тикетов с таймером стал вытеснять старые. Но уже на этом этапе началась положительная динамика. отметок 2h и 9h. Было заметно, что примерное время код-ревью концентрировалось в районе сообщений-напоминалок, т.е.

Из них 29 вышли за девятичасовую границу. На момент написания этой статьи у нас 415 тасков, в которых таймер включился. Если отбросить и их, то остаётся 17 тасков. Хотя, если внимательно приглядеться, то встречаются и такие таски, код-ревью которых завершалось в течение следующего часа. 1%! А это примерно 4.

Итог. Самурай постоянно точит свой меч

Все наши шаги привели к желаемому результату: более 92% пулл-реквестов стали удовлетворять нашему SLA! Оглядываясь назад и вспоминая все наши действия, можно сделать один вывод — все средства хороши. Потихоньку-помаленьку 75% код-ревью стало укладываться в 5 часов! Всё меньше сорванных тасков, всё быстрее проходит код-ревью. Помимо числовых показателей мы стали получать еще положительные отзывы от смежников. И динамика по улучшению до сих пор положительная. Даже такой процесс, как ускорение код-ревью, еще больше сплотил команду. Еще больше радует тот факт, как команда отнеслась ко всему этому процессу. Каждый участник стал понимать ответственность, которую он несёт перед другими, как быстрое код-ревью позволяет еще быстрее приносить пользу нашим пользователям.

Но на нём мы не намерены останавливаться. Конечно, 9h это не предел мечтаний, но всё-таки успех. Мы продолжаем отслеживать процесс код-ревью и решать все технические и даже психологические проблемы, с которыми сталкиваются сотрудники, чтобы наш процесс был максимально продуктивным и в то же время комфортным для команды.

Q&A. А что, если...?

К чему этот таймер?
A: Следим не конкретно за кем-то, а за процессом. Q: А что, если я думаю, что за мной следят? Если ревьюеры затягивают с проверкой, то страдает автор. В пулл-реквесте две стороны: автор и ревьюеры. Нужно найти баланс, чтобы комфортно было обеим сторонам. С другой стороны отрывать ревьюеров от работы прямо так сразу тоже негуманно. Большинство таких отклонений случается не по вине ревьюеров, а по вине технических проблем. Таймер нужен не для того, чтобы кого-то наказать, а для того, чтобы фиксировать все отклонения. Чтобы другие с ними не столкнулись. Задача в том, чтобы эти проблемы устранять. Постоянное самосовершенствование

Где справедливость?
A: Да, это действительно так. Q: А что, если бывают PR сложные, по 100500+ строк кода, а бывают "букву поменять". код-ревью сложных PR должно укладываться в SLA. Когда мы прорабатывали стандарт код-ревью, то как раз взяли по верхней границе, т.е. Мы всегда с пониманием относимся к пулл-реквестам, в которых идёт живое, полезное обсуждение, невзирая на сбитую планку в один день. Но при этом у нас нет цели загнать всех в эти границы.

1SP — 1h, 3SP — 5h, 5SP — 2d, к примеру. У нас в планах есть градации SLA по storypoints. Просто мы к такому еще не готовы – нам предстоит еще долгий путь совершенствования. К счастью, Трекер уже способен на такое.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть