Человек – главная ценность любого предприятия. Успех всего дела зависит от того, как люди коммуницируют между собой, как вместе добиваются поставленных целей, от командной работы. Постоянное оттачивание навыков, процессов и инструментов позволяет работать эффективней.
Мы в Маркете работаем над тем, чтобы как можно быстрее доставлять новые возможности нашим пользователям. Для этого мы постоянно изучаем наши процессы и оптимизируем все этапы работы над задачей. Сегодня мы расскажем читателям Хабра об оптимизации одного из них, а именно процесса код-ревью.
Для начала надо представить, какой флоу в разработке у нас принят:
То же самое, только по пунктам и словами:
- Разработчик берет таску.
- Делает ее.
- Заливает в Github и открывает PR.
- Проходит код-ревью.
- Собирает демо-стенд и отдает тестировщику.
- Тестировщик проверяет демо-стенд.
- Проверенную таску собирают в релиз.
- Тестирование в релизе.
- Выкладка на прод.
- Финальное тестирование на бою.
По зонам ответственности таска делится на следующие шаги:
1-5 — ответственность на разработчике;
6-7 — ответственность на тестировщике;
8-10 — ответственность на релиз-мастере.
Итак, начали анализировать, что же занимает у нас больше всего времени. Благо есть внутренние инструменты анализа. Все делали ставку на то, что дольше всего будет занимать, само собой, сам процесс разработки (статус «В работе»)… и так и оказалось. Но один момент нас удивил больше всех. Средняя продолжительность ревью — две недели!
Действие 1. Разбор PR
Начав изучать пулл-реквесты, сразу же столкнулись с одним очень интересным фактом. Оказалось, что у нас есть огромное кладбище незакрытых пулл-реквестов. Большинство авторов этих PR уже не работали в компании, но их наследие всё еще было с нами. Кто никогда не видел динозавров, то вот они:
Эти пулл-реквесты добавляли шум и мешали правильному анализу времени код-ревью. Со спокойной душой мы их позакрывали. Оставалось только пересчитать время. А оно по-прежнему было в районе 2-3 дней. Нехорошо.
Действие 2. Разборка с ревьюшницей
Ревьюшница — разработанная в Яндексе система, которая призывает в PR двух рандомных людей с экспертизой в изменяемом коде и с учетом отпусков и отсутствий. Разбор недельных PRов выявил группу лиц, которые постоянно затягивают код-ревью. Опросив данных коллег, мы нашли еще одну проблему в нашем процессе. Коллеги жаловались, что им приходит слишком много пулл-реквестов за день от ревьюшницы, и у них просто не хватает времени на их основную работу.
Это не сходилось с нашими показателями: один-два PR в день на человека. Исследование привело в Github, где у нас заведена отдельная команда ревьюеров. Эта команда не обновлялась несколько лет. С тех пор количество сотрудников увеличилось в два раза, но никто из новичков в команду ревьюеров не входил. Иначе говоря, половина команды вообще не участвовала в код-ревью! Исправили это досадное недоразумение.
Действие 3. Расширение инструментов
На этом этапе мы пытались упростить и без того простую, как мы думали, жизнь ревьюеров. В арсенале фронтендеров были следующие инструменты:
- кодстайл-чекеры;
- прогон тестов;
- различные проверки-нероняйки в самом PR;
- ревьюшница;
- оповещения на почту и в таск-трекер.
Казалось бы, всё есть. Бери и ревьюй!
Первое, что оказалось не так: разный процесс код-ревью в разных репозиториях. Унифицировали и заодно докинули проставление лейблов для удобного поиска PRов через интерфейс Github.
Второе, что заметили: почта — не лучший инструмент для быстрого информирования о статусе код-ревью. Многие, чтобы не отвлекаться от работы, разбирает свою почту несколько раз за день. Совсем другое дело мессенджеры. Реакция на сообщения в мессенджерах куда выше. И было решено подключить бота к нашему мессенджеру. Бот шлёт оповещения о статусе код-ревью как для автора пулл-реквеста, так и призывает людей поревьюить. Очень удобно.
Действие 4. Первый SLA
Параллельно действиям 2 и 3 мы начали плотно работать с сотрудниками и объяснять, что код-ревью неотделим от выполнения самой задачи. Объясняли, что доведение до «Проверено» — это ответственность разработчика. Причем ответственность не только перед коллегами, но и перед пользователями! Быстрая доставка фичи до прода — вот чего хотелось достичь. И команда с пониманием отнеслась к процессу улучшения.
На этом этапе зародилось первое представление об идеальном код-ревью. Конечно, всем хочется, чтобы оно проходило за 5 минут, но это возможно не всегда. Взяв в расчет, что у нас мультирегиональная команда (с разницей во времени в четыре часа), мы договорились, что нашим SLA будет один день, т.е. 24 часа. Огласили всем сотрудникам этот SLA и, потирая руки, стали ждать результатов.
Но ситуация так и не изменилась. В лучшие недели половина пулл-реквестов укладывалось в 1 день. Остальные так и вылезали за него.
У нас был небольшой скрипт, который оценивал время код-ревью на PR. Им мы и стали грепать на ежедневной основе все PRы в поисках "отстающих". Почти каждый день находилась пачка таких.
На их разбор уходило много времени. Чаще всего сам скрипт нечестно обсчитывал время ревью. Он не учитывал, что некоторые PRы создавали в нерабочее время (да, у нас некоторые смелые-умелые любят поработать часок-другой ночью, приходите к нам работать!). Всё это говорило нам о том, что наши инструменты мониторинга пулл-реквестов не самые эффективные, так как нечестные. Придётся найти новые инструменты.
Действие 5. Трекер SLA
Помощь пришла откуда не ждали. Наши коллеги из Трекера анонсировали удивительную вещь: теперь можно установить SLA в самом Трекере. Причем настроить его можно совершенно разнообразно. Некий таймер включается по какому-то событию в таске. По какому-то событию может вставать на паузу. И по какому-то событию останавливаться. Да это то, что нам надо!
Сразу полезли детально изучать документацию (кстати, вот она) и настраивать наши очереди (их несколько, так как несколько репозиториев). Настроили, чтобы таймер включался при переходе в статус "Need code review" и завершался при переходе в любой другой статус, кроме "Есть замечания" – при нём таймер вставал на паузу, т.е. не сбрасывал своё время.
Ещё оказалось классно то, что таймер учитывал рабочее время и календарь! Мы выставили, что на код-ревью отводится 9h, т.е. один рабочий день. При этом оповещение срабатывает через 2h после старта, или если сорвали девятичасовой срок. Получился своеобразный честный мониторинг. Поначалу мы включили таймер ради эксперимента, собрали пачку багов и отрепортили в Трекер.
Стоит отметить ещё то, что таймер включался только для тасков, которые были созданы уже после внедрения самого таймера. Поэтому мгновенного эффекта увидеть не удалось. Но уже на этом этапе началась положительная динамика. Эффект мы получили уже спустя месяц, когда поток новых тикетов с таймером стал вытеснять старые. Было заметно, что примерное время код-ревью концентрировалось в районе сообщений-напоминалок, т.е. отметок 2h и 9h.
На момент написания этой статьи у нас 415 тасков, в которых таймер включился. Из них 29 вышли за девятичасовую границу. Хотя, если внимательно приглядеться, то встречаются и такие таски, код-ревью которых завершалось в течение следующего часа. Если отбросить и их, то остаётся 17 тасков. А это примерно 4.1%!
Итог. Самурай постоянно точит свой меч
Оглядываясь назад и вспоминая все наши действия, можно сделать один вывод — все средства хороши. Все наши шаги привели к желаемому результату: более 92% пулл-реквестов стали удовлетворять нашему SLA! Всё меньше сорванных тасков, всё быстрее проходит код-ревью. Потихоньку-помаленьку 75% код-ревью стало укладываться в 5 часов! И динамика по улучшению до сих пор положительная. Помимо числовых показателей мы стали получать еще положительные отзывы от смежников. Еще больше радует тот факт, как команда отнеслась ко всему этому процессу. Даже такой процесс, как ускорение код-ревью, еще больше сплотил команду. Каждый участник стал понимать ответственность, которую он несёт перед другими, как быстрое код-ревью позволяет еще быстрее приносить пользу нашим пользователям.
Конечно, 9h это не предел мечтаний, но всё-таки успех. Но на нём мы не намерены останавливаться. Мы продолжаем отслеживать процесс код-ревью и решать все технические и даже психологические проблемы, с которыми сталкиваются сотрудники, чтобы наш процесс был максимально продуктивным и в то же время комфортным для команды.
Q&A. А что, если...?
Q: А что, если я думаю, что за мной следят? К чему этот таймер?
A: Следим не конкретно за кем-то, а за процессом. В пулл-реквесте две стороны: автор и ревьюеры. Если ревьюеры затягивают с проверкой, то страдает автор. С другой стороны отрывать ревьюеров от работы прямо так сразу тоже негуманно. Нужно найти баланс, чтобы комфортно было обеим сторонам. Таймер нужен не для того, чтобы кого-то наказать, а для того, чтобы фиксировать все отклонения. Большинство таких отклонений случается не по вине ревьюеров, а по вине технических проблем. Задача в том, чтобы эти проблемы устранять. Чтобы другие с ними не столкнулись. Постоянное самосовершенствование
Q: А что, если бывают PR сложные, по 100500+ строк кода, а бывают "букву поменять". Где справедливость?
A: Да, это действительно так. Когда мы прорабатывали стандарт код-ревью, то как раз взяли по верхней границе, т.е. код-ревью сложных PR должно укладываться в SLA. Но при этом у нас нет цели загнать всех в эти границы. Мы всегда с пониманием относимся к пулл-реквестам, в которых идёт живое, полезное обсуждение, невзирая на сбитую планку в один день.
У нас в планах есть градации SLA по storypoints. 1SP — 1h, 3SP — 5h, 5SP — 2d, к примеру. К счастью, Трекер уже способен на такое. Просто мы к такому еще не готовы – нам предстоит еще долгий путь совершенствования.
Комментарии (35)
Femistoklov
24.08.2018 15:07+1Исследование привело в Github, где у нас заведена отдельная команда ревьюеров. Эта команда не обновлялась несколько лет. С тех пор количество сотрудников увеличилось в два раза, но никто из новичков в команду ревьюеров не входил. Иначе говоря, половина команды вообще не участвовала в код-ревью! Исправили это досадное недоразумение.
— Вася, ты теперь будешь в команде код-ревью.
— ??? (Что это, повышение? Уже пару лет спокойно работаю, ни о каких ревью разговора не было. Ревьюят же только здешние старожилы — по совместительству ценные ключевые сотрудники, могут себе позволить. А я всего лишь рядовой программист...)
— Будешь делать всё то же, что и раньше, только теперь ещё и ревьюить по 2 пулл-реквеста в день на 10 экранов каждый из рандомных частей проекта. И только попробуй не уложиться в 24 часа.
— Окееей…Komaroni Автор
24.08.2018 15:49+1У нас в команде не принято создавать PR на «10 экранов». Мы стараемся декомпозировать задачи так, чтобы их возможно было и быстро кодить, и ревьюить, и тестировать.
Что по поводу 24 часов (а точнее 9h) — это договоренность, которой мы достигли всей командой. Мы вместе пришли к тому, что нам комфортнее будет проводить код-ревью за данное время.
В то же время, мы не заставляем обязательно укладываться за один день. Цитирую:
Мы всегда с пониманием относимся к пулл-реквестам, в которых идёт живое, полезное обсуждение, невзирая на сбитую планку в один день.
fobos
24.08.2018 19:50+1— Будешь делать всё то же, что и раньше, только теперь ещё и ревьюить по 2 пулл-реквеста в день на 10 экранов каждый из рандомных частей проекта. И только попробуй не уложиться в 24 часа.
Излишне категорично. Кодревью это такая же работа как написание кода или выяснение требований по задачам. Если понадобится, то и целый день можно потратить на ревью.JediPhilosopher
24.08.2018 20:58+3Кодревью это такая же работа как написание кода
Ну может в каком-нибудь сферическом Яндексе в вакууме это так. Но вот во всех конторах где работал я, ревью рассматривалось как некая дополнительная нагрузка. Оценивался разработчик именно по скорости выполнения задач, а с ревью важность имело только критическое неуспевание (висящие долго пуллреквесты), за которое можно было получить по шапке. В итоге все время перекосы и тяжелые муки выбора — то ли делать свою задачу, с риском задержать какую-то важную фичу, ждущую ревью, то ли ревьюить, а потом оправдываться почему задачу не сделал в срок.
И дело даже не в том что за это как-то особо серьезно ругали, а именно в этом лишнем головняке выбора на что тратить рабочее время.OlegKrasikov
27.08.2018 10:24Это проблема того, как команда понимает «Закрытая задача».
Например, у нас закрытая задача — это фича, которая находится в продакшене.
Если у тестировщика проблема, ему помогает ее решить команда. Если в ходе деплоя проблема, ее помогает решить команда.
Задача разработчика не равна написать код, задача разработчика решать проблемы. Написаный, но не не отревьювенный и не отттестированный код, который не находится в продакшене — это нерешенная проблема.
Судя по вашему комментарию, у вас не было команды, а был босс и отдельные подчиненный, и это уже проблема менеджмента.
Wolonter
24.08.2018 15:18+1Многие, чтобы не отвлекаться от работы, разбирает свою почту несколько раз за день. Совсем другое дело мессенджеры. Реакция на сообщения в мессенджерах куда выше. И было решено подключить бота к нашему мессенджеру. Бот шлёт оповещения о статусе код-ревью как для автора пулл-реквеста, так и призывает людей поревьюить. Очень удобно.
Отвлекать в мессенджере — мерзко. Повышать культуру работы с почтой, конечно же, намного сложнее.
Вы озвучили одну проблему — новые сотрудники со временем не становились ревьюерами, из-за этого старые имели сверхнагрузку. Остальное не проблемы, а факты и особенности, не влияющие на скорость.
Вопрос: вы изменили скорость, добавили квадриллион напоминалок. Как поменялось качество ревью?Komaroni Автор
24.08.2018 16:17+1Отвлекать в мессенджере — мерзко. Повышать культуру работы с почтой, конечно же, намного сложнее.
Бот в мессенджере — как одна из опций. Все люди разные, и по-разному строят свою работу. Коллеги, которым удобнее получать сообщения по почте, могут даже не включать оповещения в мессенджере.
Некоторые просматривают PRы непосредственно через GitHub в определенный промежуток времени своего рабочего дня — это нормально. Потому и SLA у нас — один рабочий день.
Как поменялось качество ревью?
Качество ревью довольно сложно измерить. По нашим меркам качество ревью не изменилось. Также мы стараемся по максимуму автоматизировать всевозможные проверки, чтобы ревьюеры фокусировались исключительно на самом важном.
fobos
24.08.2018 19:46Вопрос: вы изменили скорость, добавили квадриллион напоминалок. Как поменялось качество ревью?
Скажу за себя. Я как ревьювил так и продолжаю. Т.е. от напоминаний хуже делать его не стал, иначе в чём смысл? Таким темпом можно добиться прохождения ревью и за 10 секунд.
SeriousDron
24.08.2018 15:21Итого: обнаружили что код-ревью занимает долго, оказалось неправильно считали и почему-то этим занимаются не все.
Почему вообще все программисты не могут делать ревью, а не только особо провинившиеся?Komaroni Автор
24.08.2018 16:01+1Так и есть: абсолютно все могут делать ревью. Ревьюшница случайно выбирает двух человек из всей команды. Причем она равномерно распределяет нагрузку по всем.
И даже если ревьюшница не призвала в PR — есть возможность провести ревью на добровольных началах.
ShockwaveNN
24.08.2018 17:11Ревьюшница — разработанная в Яндексе система, которая призывает в PR двух рандомных людей с экспертизой в изменяемом коде и с учетом отпусков и отсутствий
Мне кажется очень часто в командах не бывает двух людей с глубоким понятием изменяемого кода, а если они еще рандомно избираются — то их должно быть больше.
То есть возник вопрос сколько человек вообще участвует в разработке продукта и в этой "случайной выборке двух ревьюверов"fobos
24.08.2018 19:57На данный момент в группе на гитхабе из которой ревьюшница выбирает ревьюверов значится 31 человек.
JediPhilosopher
24.08.2018 21:00+1Мне кажется очень часто в командах не бывает двух людей с глубоким понятием изменяемого кода
А это как раз одна из проблем, с которой ревью признано бороться. Если в компании много кода, в котором разбирается только написавший его человек, то компания огребет очень много проблем если с этим человеком что-то случится (заболеет, уволится, пресловутый «bus-factor»). Так что ревью — это в том числе и повод членам команды лучше разобраться в других частях кода, который писали не они.
HeOS
24.08.2018 17:37Статья интересная, спасибо!
Так же интересно было бы узнать про то, как у вас реализуются пункты 5-9. Автоматизированы ли они? Что используете?
Немного вот об этом:
Ревьюшница — разработанная в Яндексе система, которая призывает в PR двух рандомных людей с экспертизой в изменяемом коде и с учетом отпусков и отсутствий.
Смотрели ли вы сторону open-source решений, таких как Gerrit, например? То же Openstack-сообщество на его основе построило довольно удобное и функциональное воркфлоу. Конечно, одним герритом там не обошлось, рядом есть еще парочка других инструментов (Zuul и Jenkins, например).
Огромный плюс геррита в том, что у него имеется довольно простой API, вокруг которого можно построить довольно удобные CI/CD процессы. Кроме того, геррит позволяет гибко настроить workflow, благодаря использованию дополнительных плагинов и лейблов/оценок.fobos
24.08.2018 20:07Так же интересно было бы узнать про то, как у вас реализуются пункты 5-9. Автоматизированы ли они?
Если ответить коротко, то, да автоматизированы. Как только разработчик создал ПР, помимо ревьюшницы приходит ещё один бот, который запускает небольшой пайплайн в который входят:
- Сборка проекта
- Выкладка в тестовом окружении
- Запуск автоматических интеграционных и e2e тестов
- Анализаторы деградаций различных метрик
Отсюда вытекает что именно на ручное тестирование уходит на так много времени. Далее тикет попадает в другой уже релизный пайплайн с похожим набором шагов, но их там гораздо больше.
Что касается используемых для этого решений, то там в основном всё собственного производства.
А вообще это тема для отдельной большой статьи.
TheGodfather
24.08.2018 20:09+2Геррит после гитхаба? Вы серьезно?
HeOS
24.08.2018 20:16+2Да, а что? Я пользовался и тем, и тем и считаю, что геррит куда удобнее, нежели гитхаб.
Геррит гибче в настройке workflow, геррит гибче и удобнее в ревью кода — например, такая маленькая фича, как возможность выделить кусок кода и оставить комментарий к нему, очень удобна. Я уж не говорю про все остальное.
У вас негативный опыт его использования? Расскажите, пожалуйста.TheGodfather
25.08.2018 09:36+1На гитхабе можно оставлять комменты по строкам.
У нас сейчас в компании используется геррит, в нем есть конечно свои плюсы (vim-гикам понравится, минималистичный интерфейс из 90-х), но из основного:
— Зависит от команды, но на мой взгляд branch-based ревью намного ближе к жизни, чем commit-based. В Геррите вы ревьювите каждый коммит, в Гитхабе вы ревьювите весь ПР, т.е. ветку (и, конечно, все еще остается возможность видеть отдельные коммиты в этой ветке). И новая фича обычно это не один и не два коммита (перед финальным сквошем).
— Гитхаб это же в целом интегрированное решение: репозиторий, ревью и багтрекер вместе. А Геррит идет как надстройка к репозиторию, поэтому интеграция между ними меньше (банально — подсветка ссылок из коммита «Related to PR #123»)
— В проектах на гитхабе зачастую видел хорошо настроенных ботов на проверку код стайла, например. И отображение результатов наглядно бейджиками и цветной циферкой (плюшки, да, но из маленьких мелочей и складывается общее удобство). Прямо автоматически добавляет комменты на строки, где что-то не так. Не копал сильно насчет интеграции подобного в геррит, но есть ощущение, что если бот и есть, то может только финальный «Verified -1» поставить, без комментариев инлайн.
lamerok
24.08.2018 19:23Мы тоже в пиир ревью захлебывались, после чего решили, что пир ревью делают из команды только 2 человека. Например, в команде 5 человек. У каждого по задаче (в задачу входит — разработка детальной архиетктуры, ревью, разработка кода, юнит тестирование, ревью кода). Договоренность такая, что каждый посылает только 2 из команды, (в задаче указываем кто ревьюит) таким образом в ревью задействованы все разработчики и на 1 разработчика из 5 задач выходит 2- 3 задачи. Задачи небольшие, так чтобы не больше 50 линий кода, чтобы в течении 10 минут ревью было сделано. Если есть вопросы по замечаниям, собираются трое (автор и двое ревьюйщиков). Обычно получается решить, все быстро 20-30 минут на ревью одной кода или дизайна. Основное время ревью на дизайне, код уже по дизайну делается просто, там замечаний не так много.
Самое главное что в команде программисты разных уровней, но все в итоге делают ревью, получается все в курсе всего и учатся друг у друга.
BalinTomsk
24.08.2018 22:03+1Как-то у вас просто.
У нас:
— code + written unit tests + functional tests
— pre-review 2 чела + team lead
— submit to development tree
— post review 2 чела
— тестировщики и load tests
--…lamerok
24.08.2018 22:37:) полный процесс примерно такой:
Вначале общая архитектура, потом разбивается на спринты, в спринтах задачи по 2 дня максимум. Задача включает в себя
— детальный дизайн + ревью (один опытный, второй любой)
— код, юнит тесты, смок тесты — ревью кода (2 человека, один опытный, второй любой)
— задача сливается
— в конце спринта, еще раз смок тесты все для всех задач и сборка спринта
— тестирование спринта у тестеровщиков…
abby
24.08.2018 22:42Сколько у вас обычно раундов комментирования в одном код-ревью?
Мы продолжаем отслеживать процесс код-ревью и решать все технические и даже психологические проблемы
Вот на последнем пункте можно поподробнее? К примеру, что вы делаете, когда люди завалены демотивирующими код-ревью? Демотивируют, потому что код, мягко говоря, «пахнет», а автор сопротивляется исправлять.
funca
24.08.2018 23:48-1- Как сократить время на ревью?
- Давать меньше времени на ревью.
В следующей серии:
- Чем принципмально отличаются этстимации в сторипоинтах от оценки в нормочасах?
- Ни чем.
рецепты эффективного менеджмента
borv
25.08.2018 02:03Автоматизация — это отлично. В остальном мы пошли по другому пути. Можно сказать в обратном направлении. Выглядит это так.
Код ревью занимает столько, сколько занимает и "ускорить" его нельзя. Тестировщиков у нас как таковых нет. Доказательность того, что все работает — это один из аспектов ревью. Хотите — читайте код, хотите — предъявляйте тесты, хотите — шагайте через код дебагером. Ваша задача убедить ревьювера, а он будет упираться. Почему? Потому что, за вынос в прод отвечает не автор, а ревьювер. Если вы напороли, разбираться будете вдвоем, но ответственность именно на ревьювере. Это чтобы народ серьезнее к этому процессу относился а не глянул по диагонали, тесты проходят — и +2. Как результат ревью по три десятка итераций вполне норма.
А как сделать так, чтобы ревью не уходило в бесконечность? На то есть менеджеры. У них есть право и обязанность любыми доступными методами, кроме запрещенных в code of conduct, тянуть разработчиков в сторону закрытия историй. У нас это специальные барышни, которые отвечают за набор историй. Сейчас конкретно их две на наш отдел в 30 человек. Могут три раза на дню прийти поспрашивать как дела и что держит. Могут попросить назначить другого ревьювера и т.д. Если ревьювер и автор уперлись, могут пригласить третьего в качестве арбитра. Если застряли на координации, будут носиться между командами и сводить концы. Если что-то поменялось будут обновлять истории и доносить это до инженеров. Это их работа, главным образом персонально-коммуникационная, и справляются они с ней на ура. Опять же не из альтруистических соображений — если ревью зависло на месяц, есть шанс что всю фичу зарубят как невыполнимую и снесут в бэклог. Им тогда объясняться с кучей народа, в том числе директорами и спонсорами. И OKR могут посыпаться.
Кстати, подчиненных инженеров у барышень нет и начальством они формально тоже не являются (разве только между собой). Это для того, чтобы они обслуживали процесс а не рулили им. В противном случае будет "сделай как я говорю или премия минус".
В целом работать намного комфортнее чем в конторе с кучей мотивационных метрик (я и там был в свое время), а впечатление очень положительное. Когда у вас "ревью в 24 часа" и "история в день", фокус неизбежно сползает с работы на удовлетворение системы или ее надувательство. Конкретно пример из "метрической" конторы (каюсь): иногда если ревью сложное, а мне надо еще кучу всего сделать, я его просто рубил его "за несоответствие требованиям", благо всегда можно прицепиться. Автор понимал что я в зашиве и возвращал историю продакту. Они всегда перегружены, так что пару дней есть пока они доберутся. Потому 10 минутный митинг с чтением истории вслух, уточнение одного предложения, подъем ревью, а у меня уже было время код почитать. Так погоняешь ревью кругами — у всех метрики на ура, коллаборация претъ, все счастливы. Только сплошная Кафка какая-то, причем я не про технологию.
Arris
25.08.2018 11:39+1Реакция на сообщения в мессенджерах куда выше. И было решено подключить бота к нашему мессенджеру. Бот шлёт оповещения о статусе код-ревью как для автора пулл-реквеста, так и призывает людей поревьюить. Очень удобно.
А какой у вас мессенджер?
zoooppy
25.08.2018 12:28Практикуете ли парное программирование?
У меня подобного опыта не очень много, но периодически какие-то задачи с коллегами решаем на пару. При этом код-ревью проходит довольно быстро (ревьювит 1 человек т.к. над задачей работали 2) и субъективно проблем с таким кодом потом меньше.
isam_os
25.08.2018 12:30-2вы хоть определитесь… либо русский язык… либо непонятно английкий… я конечно понимаю… но давайте тогда все слова коверкать )) а не избранные… «берет таску » тогда уж гетает таск… експиринс крю яндекс маркит……
Scf
25.08.2018 13:49А кто у вас мерджит PR в случае конфликтов — разработчик или ревьювер?
fobos
27.08.2018 10:46+1Разработчик в ветке которого происходит конфликт. Плюс он привлекает людей с чьим кодом конфликты. Если разработчик по какой-то причине не может быстро отреагировать, то к этому привлекаются другие разработчики близкие к этой проблеме, в том числе и ревьюверы.
Scf
27.08.2018 10:52Не думали о том, что в случае конфликта мерджить должен ревьювер?
Очень хорошо мотивирует рассматривать PR вовремя.fobos
27.08.2018 12:01Так ревью вовремя и конфликты при слиянии не сильно связаны друг с другом. То, что я вовремя поревьювил, не означает, что конфликтов на слиянии не будет.
Разве что вы имеете ввиду, что ПР быстро устаревает и повышется риск возникновения конфликтов. Ну да, это так. Но, в нашем случае разработчику тоже не интересно, чтобы его тикет долго висел в ревью, поэтому он всё равно не исключается из процесса и наблюдает за статусом своих ПР.Scf
27.08.2018 12:04Разве разработчики не делают rebase целевой ветки (master/development) в свой PR перед сабмитом на ревью? Тогда свежий PR гарантированно мерджится без конфликтов.
kITerE
Спасибо, интересный опыт
Что используете в качестве мессенджера?