Комментарии 21
А почему выбран тип float64 для идентификаторов?
Была паника с int32 поэтому поправил:
panic: interface conversion: interface {} is float64, not int32
А что если использовать более масштабное решение, у меня как раз сервис сейчас обрабатывает похожую информацию для оценки код ревью - PullKeeper? Он считает затраченное время на ревью, отправляет уведомления.
Писал о нём статью - https://habr.com/ru/articles/794522/
не совсем понял, в чём проблема была. Когда создаёшь запрос на инспекцию кода в любой системе контроля версий, то всем участникам инспекции кода на рабочую почту приходит письмо. Дальше люди инспектируют код. Код потом исправляется и/или благополучно сливается с основным кодом.
Конечно, процесс застопорится, если люди игнорируют уведомления или забывают о них. Это, мягко говоря, довольно странно. Или людям нет дела до того, какой код оседает в репозитории. Или они загружены по самое не могу.
Похоже на техническое решение управленческой проблемы.
Или сам процесс уведомлений неэффективен. Чем дольше человек в компании, тем больше он получает писем. И письма с ревью и прочими письмами в компании совсем не дают результата, т.к. разгребание почты и чатиков может занять очень много времени.
Ежедневное напоминание о задачах по ревью очень выручает, т.к. перед глазами всегда есть удобная сводка пулл-реквестов, по которым нужно что-нибудь сделать. При сильном загрузе на основе этой сводки можно даже букать время в календаре под процесс ревью, тогда он проходит в разы быстрее.
надо читать все рабочие письма (раз в день хотя бы), смотреть новые коммиты в репозиториях, заходить на все рабочие порталы. Даже если не было письма, сам увидишь новую инспекцию кода. А чем ещё заниматься на работе?
А вот тупить в чатах с поздравлениями ДР и прочей чепухой не надо, синхронное общение только от работы отвлекать будет.
Можно, например, работать, выполняя свои непосредственные обязанности, в которые обычно не входит мониторинг всего и вся.
Не понимаю вашего сопротивления более удобной формы уведомлений в виде агрегации всего кода, который необходимо посмотреть.
У меня, например, открыт доступ к 200+ репозиториям, и если я буду заниматься мониторингом всего и вся, я только на него и буду тратить весь свой рабочий день даже вместо самого ревью. А так я каждый жень получаю уведомления от бота, который мне говорит "посмотри реквесты, порешай конфликты, зарезолвь треды где ты ответственен". Вместо выковыривания информации по крупицам я сразу получаю удобный инструмент для работы. И это в разы лучше, чем пинговать людей с разным графиком и подходом к работе на предмет ревью кода, плюс заниматься этим вручную.
не надо никого пинговать - всё видно в репозитории, кто чем занимался.
Про 200 репозиториев не понял - как можно работать над 200 проектами с кодом одновременно? Один проект разбит на 200 репозиториев - тоже бред. Тысячи коммитов каждый день?
Смотреть репозитории надо только те, над которыми сам работаешь на своей работе на одном-единственном проекте. Это 1-2 репозитория на практике.
А если не занимался? Тут и приходят на помощь доп. уведомления. И либо они вручную через чат вроде "посмотри плиз", либо через автоматизацию, которая на практике выигрывает человеческому фактору, что и показали метрики в посте.
Репозиторий не обязательно может являться проектом. Там может быть переиспользуемый библиотечный или инфраструктурный код. И чем дольше работаешь, тем чаще ты в тот или иной репо можешь добавить свои коммиты, чтобы задачку продвинуть связанную. Естественно, никто не говорит про овнерство 200 репозиториями. Но даже у одной команды может накопиться десяток репозиториев с поддержкой кода.
На мой взгляд проблема организационная, а вы пытаетесь решить её техническим способом. Тут уже заметили в комментариях, что любая более-менее зрелая система, в которой есть возможность делать код ревью, имеет систему уведомлений. Вы бы лучше написали, почему эта система в вашем случае не работала. Вот отсюда и надо начинать решение.
При создании мр в gitlab действительно приходят уведомления на почту, но как оказалось на практике, почту мало кто просматривает полностью и не всегда она открыта. Рабочий чат всегда под рукой и откликаются сотрудники именно на него. Ну и цифры сами говорят за себя, как технический способ улучшил показатели.
А так ли прям срочно человек должен все бросать и бежать делать ревью, как только приходит сообщение? Обычно разработчики погружены в контекст решаемой задачи и редко кто готов все бросить и сию же минуту переключиться на ревью. А не любят они это делать часто и срочно потому, что переключение контекста затратно и контрпродуктивно, особенно при решении сложных и нетривиальных задач. А чтобы сделать ревью качественно, а не абы как, нужно иногда потратить больше 10 минут и даже разобраться в контексте сделанных изменений.
Я могу поделиться, как у меня ребята решают эту, прямо скажем не новую и уникальную, проблему. Достаточно взять за привычку каждое утро начинать с ревью задач. Так и контекст переключать не надо, и со свежей головой разбираться в чужом коде намного эффективнее получается. И не надо писать бота.и потом и его ещё поддерживать. Но конечно, ситуации бывают разные. Если у вас вечный аврал и нужно часто что-то ревьюить в течение дня и деплоить несколько раз за день, то вариант с чатом будет эффективнее.
Об этом я также писал, что мы выносили эту проблему на ретро. И то что каждый из разработчиков поверяет в начале дня мр команды было первым пунктом, но как мы видим это не помогло и мы сделали инструмент, который улучшил показатели
Я даже знаю, почему не помогло. Это скорее всего потому, что каждый член команды считает своей обязанностью только свою задачу. Код ревью обычно не любят (и не хотят соответственно) делать и не считают это важным в работе. Отчасти, потому что это большинству неинтересно (интереснее код писать), отчасти, что обычно на это не планируют время явно. Эта проблема стара как мир. Чтобы заработало, надо создать условия.
Закладывайте время для код ревью при планировании.
Донесите до людей, что их обязанность не только код писать по своей задаче, а ещё помогать чужим задачам быть доставленными конечному клиенту. А для этого они должны делать ревью, которое на них назначили. Это должна быть общая ответственность за доставку. Каждый разработчик должен понимать, что просто написанный и отправленный на ревью код != завершенная задача != профит для компании != за что они получают деньги. Основная цель - решить проблему клиента. А этого сделать не получится, если код не доставлен клиенту,. А без ревью доставить не получится.
Спросите, что нужно поменять в работе, чтобы это было реально и удобно для них. Поменяйте процессы соответственно.
Но опять же, это должен делать руководитель, а не вы. Но вы пытались решить проблему своим способом, как можете. Если в данном случае это помогло, то ок. Но это как лечить зубы полосканием солёной водой вместо похода к стоматологу. Изначальная проблема в другой плоскости.
А ваши метрики вполне естественно показывают рост, потому что разработчики обращают внимание на сообщения бота. Но ваши метрики надо рассматривать вкупе с метриками общей продуктивности команды. И скорее всего там убыло. Как раз из-за дополнительного времени на переключение контекста.
Нагрузка на каждого из разработчиков по задачам не изменилась. Отчеты по по проджам, производительности команды также не ухудшилась.
Ну ок. Что очень странно. У вас люди теперь больше времени тратят на ревью, да ещё на переключение контекста, но общие метрики остались такими ми же. Вы же 8 часовой рабочий день не увеличивали? Ну тогда откуда взялось дополнительное время? Ребята перерабатывают теперь? Или раньше не дорабатывали?)
Ещё может быть такое, что они просто меньше времени тратят на ревью. Раньше смотрели более тщательно. Теперь пробежались быстро, поставили аппув и все. От этого может страдать качество задач, а может и не страдать. Зависит от опытности людей в команде. Главное, чтобы все были довольны. Если у вас все хорошо, значит вы делаете правильные вещи.
Вообще, подозреваю, что проблема у вас просто в том, что разработчики не хотят настраивать уведомления и фильтры в почте. Когда сыплется много всего, естественно это превращается в шум и никто на это не обращает внимания. Поэтому ваши уведомления на почту неэффективны. Решается это на управленческом уровне донесением знаний до команды, как это настроить и каждому индивидуально помогать, если человек сам не может сделать уведомления эффективными. Но конечно, это должен делать руководитель, а не вы, это его прямая обязанность - настроить процессы работы команды наиболее эффективно.
Как я написал для своей команды бот-напоминалку на Golang и втрое сократил время на ревью задач