Вы же техлид. А это уже не простой разработчик. Видимо, в Яндексе есть отдельные люди, которые актуальность пакетов мониторят. Но в тех компаниях, в которых работал я, эти вопросы всегда входили в обязанность тех/тим лида. Иногда с консультацией со стороны безопасников или сторонней компании, которая аудит делает. Но всегда за это отвечал в первую очередь технический руководитель. И это нормально, ибо он лучше всех знает продукт, что там используется и какие решения могут представлять потенциальный вектор для атаки. Но если у вас этим отдельные люди занимаются, ну хорошо.
Потому что - это модно, молодежно) А автор статьи - питон-евангелист. Разве не чувствуете, как он взахлёб новые фичи перечисляет. Я некоторые предложения не до конца понял, так все быстро. Шучу конечно)
А если серьезно, то очень странно, что две основные причины, ради которых обычно затевается это часто недешевое для бизнеса удовольствие, в статье не упомянуты. Это безопасность и исправление критичных ошибок. Выше уже написали про безопасность, security patches, уязвимости и вот это все. Так же часто обновляют, чтобы закрыть баги или какие-то вещи, которые работают не совсем, как должны или доставляют неудобства пользователям продукта или разработчикам. Ну и обновляться нужно своевременно, чтобы не получилось, как у автора комментария выше про больше месяца работы и много боли.
Статью надо было назвать вроде "Какие крутые вещи может предложить Python" или что-то в таком духе. А текущий заголовок и правда в статье не раскрыт.
Очень часто большую часть времени в установке зависимостей занимает сборка какого-нибудь пакета из исходников, потому что нет готового бинарника под нужную архитектуру. А ту скорость, про которую написано в статье, вы будете ощущать только при установке окружения начисто с нуля, что происходит... ну пару раз за несколько месяцев? может... Так что самый большой плюс получают наверное те, кто постоянно устанавливает что-то и желательно с нуля.
Зато есть жирный минус, перекрывающий сомнительный "самый огромный" плюс - Платформозависимые lockfile. То есть, я либо использую для разработки и деплоя одну платформу, либо виртуализация, эмуляция и и иже с ними. Хотя даже питон сам по себе платформонезависимый, и собрать можно практически под любую архитектуру, и разрабатывать и запускатьь код в большинстве случаев без шаманства на разных архитектурах.
Так что я прям даже не знаю, я лучше заюзаю pdm или poetry. Не так быстро ставят, зато экономят время на разработку в целом без пляски с архитектурами.
Я даже знаю, почему не помогло. Это скорее всего потому, что каждый член команды считает своей обязанностью только свою задачу. Код ревью обычно не любят (и не хотят соответственно) делать и не считают это важным в работе. Отчасти, потому что это большинству неинтересно (интереснее код писать), отчасти, что обычно на это не планируют время явно. Эта проблема стара как мир. Чтобы заработало, надо создать условия.
Закладывайте время для код ревью при планировании.
Донесите до людей, что их обязанность не только код писать по своей задаче, а ещё помогать чужим задачам быть доставленными конечному клиенту. А для этого они должны делать ревью, которое на них назначили. Это должна быть общая ответственность за доставку. Каждый разработчик должен понимать, что просто написанный и отправленный на ревью код != завершенная задача != профит для компании != за что они получают деньги. Основная цель - решить проблему клиента. А этого сделать не получится, если код не доставлен клиенту,. А без ревью доставить не получится.
Спросите, что нужно поменять в работе, чтобы это было реально и удобно для них. Поменяйте процессы соответственно.
Но опять же, это должен делать руководитель, а не вы. Но вы пытались решить проблему своим способом, как можете. Если в данном случае это помогло, то ок. Но это как лечить зубы полосканием солёной водой вместо похода к стоматологу. Изначальная проблема в другой плоскости.
Ещё может быть такое, что они просто меньше времени тратят на ревью. Раньше смотрели более тщательно. Теперь пробежались быстро, поставили аппув и все. От этого может страдать качество задач, а может и не страдать. Зависит от опытности людей в команде. Главное, чтобы все были довольны. Если у вас все хорошо, значит вы делаете правильные вещи.
Ну ок. Что очень странно. У вас люди теперь больше времени тратят на ревью, да ещё на переключение контекста, но общие метрики остались такими ми же. Вы же 8 часовой рабочий день не увеличивали? Ну тогда откуда взялось дополнительное время? Ребята перерабатывают теперь? Или раньше не дорабатывали?)
Вообще, подозреваю, что проблема у вас просто в том, что разработчики не хотят настраивать уведомления и фильтры в почте. Когда сыплется много всего, естественно это превращается в шум и никто на это не обращает внимания. Поэтому ваши уведомления на почту неэффективны. Решается это на управленческом уровне донесением знаний до команды, как это настроить и каждому индивидуально помогать, если человек сам не может сделать уведомления эффективными. Но конечно, это должен делать руководитель, а не вы, это его прямая обязанность - настроить процессы работы команды наиболее эффективно.
А ваши метрики вполне естественно показывают рост, потому что разработчики обращают внимание на сообщения бота. Но ваши метрики надо рассматривать вкупе с метриками общей продуктивности команды. И скорее всего там убыло. Как раз из-за дополнительного времени на переключение контекста.
А так ли прям срочно человек должен все бросать и бежать делать ревью, как только приходит сообщение? Обычно разработчики погружены в контекст решаемой задачи и редко кто готов все бросить и сию же минуту переключиться на ревью. А не любят они это делать часто и срочно потому, что переключение контекста затратно и контрпродуктивно, особенно при решении сложных и нетривиальных задач. А чтобы сделать ревью качественно, а не абы как, нужно иногда потратить больше 10 минут и даже разобраться в контексте сделанных изменений.
Я могу поделиться, как у меня ребята решают эту, прямо скажем не новую и уникальную, проблему. Достаточно взять за привычку каждое утро начинать с ревью задач. Так и контекст переключать не надо, и со свежей головой разбираться в чужом коде намного эффективнее получается. И не надо писать бота.и потом и его ещё поддерживать. Но конечно, ситуации бывают разные. Если у вас вечный аврал и нужно часто что-то ревьюить в течение дня и деплоить несколько раз за день, то вариант с чатом будет эффективнее.
На мой взгляд проблема организационная, а вы пытаетесь решить её техническим способом. Тут уже заметили в комментариях, что любая более-менее зрелая система, в которой есть возможность делать код ревью, имеет систему уведомлений. Вы бы лучше написали, почему эта система в вашем случае не работала. Вот отсюда и надо начинать решение.
Я имел ввиду задачи, которые закрывают люди, которых вы набираете, а не вы сами.
Да на самом деле неважно, какие конкретно задачи. Любую задачу можно сделать так, что вроде как задача и готова, исполнитель ее закрыл, а по факту сделана некачественно. И это выясняется в процессе эксплуатации, и не факт что сразу.
Я очень рад за вас, если ваши исполнители все делают качественно и в срок и никогда не косячят. Но это не значит, что везде такие же задачи, как у вас и такие же бравые ребята. И контроль качества в любом деле лишним не бывает, а иногда и жизненно необходим.
продуктивность достаточно просто считается - количество задач, которое моя команда може сделать за какое-то время
Если ваша метрика продуктивности опирается только на количество сделанных задач, то это так себе метрика. В моей практике были люди, которые задачи пачками закрывали. Только за ними потом приходилось переделывать, потому что задача либо не покрывала все требования, либо кучу нюансов не учитывала, а иногда и работала через раз. Без метрики качества и ее отслеживания во времени кол-во закрытых задач - такой себе показатель.
А откуда у вас такая статистика?)) Общемировой тренд как раз таки другой - увеличение возраста родителей до появления первого ребенка. Причиной тому желание построить карьеру, пока молодой, увеличение продолжительности жизни, больше возможностей для женщины не зависеть от мужчины и семьи и ещё много других мелких. Поэтому люди могут заводить первого ребенка и в 30 и позже. А в таком возрасте специалист уже может дорасти и до уровня сеньера. Ну и не все останавливаются на 1 ребенке, у меня например 2 и третий на подходе. А я уже который год работаю на руководящей позиции. У многих моих знакомых от двух детей, и их больше, чем тех, у кого один.
Наличие маленьких детей редко коррелирует с уровнем профессионализма) Может быть конечно сеньер чуть лучше работает с постоянно отвлекающими и орущими детьми, но вряд ли разница сильно заметна. В обоих случаях получается хуже, чем без отвлекающих факторов.
Ну если лично у вас таких проблем не было, это не значит, что их не существует. Это лишь говорит о том, что вы с ними не сталкивались. А я сталкивался и докер эту проблему отлично решает. И ещё много других. Не стоит судить от полезности инструмента только лишь по применимости или не применимости именно в вашей работе. Это как минимум не репрезентативно. Если для вас это избыточная абстракция - замечательно. Но для тех, кто его использует для решения своих задач - это полезный рабочий инструмент.
Докер унифицирует среду выполнения и процесс сборки и запуска в ней. Это значительно исключает ситуацию бага и разработчика, у которого "все работает локально, ничего не знаю", а там оказывается версии библиотеки в ОС у разраба и на сервере разные. Так что зря вы на докер катите. Это одна из хороших практик и необходимость, нежели переусложнение. Вдобавок докер изолирует все зависимости от системы, и у вас исключается ситуация, когда один проект требует одну версию интерпретатора/компилятора и версии библиотек в системе, а другой -другие, а третий - третьи. И как вы все это будете устанавливать и обслуживать на одной машине без изоляции - большой вопрос и отдельная очень "интересная" тема.
Версии то есть в апи, только вот если у вас много внешних потребителей этого апи, на которых вам сложно повлиять, то заставить их переползти на новую версию может быть очень не быстро. Ибо доп. затраты для компании-партнёра, а профит не очевиден, итак же все работает. Так что с версиями надо быть аккуратнее и делать по возможности без них, либо с минимальным из количеством. А то может случиться, что поддерживать их придётся если не вечно, то очень долго.
Этого вполне можно добиться, если конфигурация проекта локально отличается от конфигурации на сервере. Например, фиче-флаги выставлены по-другому. С этим надо быть аккуратнее))
Это вы меня извините) На моей практике изменение именно апи слоя не вызывало каких-то серьезных затрат. Значительное время обычно занимала как раз изменение логики работы с апи и подготовки данных запроса и ответа. Поэтому название статьи интерпретировал не так, как вы задумыаали.
Вы же техлид. А это уже не простой разработчик. Видимо, в Яндексе есть отдельные люди, которые актуальность пакетов мониторят. Но в тех компаниях, в которых работал я, эти вопросы всегда входили в обязанность тех/тим лида. Иногда с консультацией со стороны безопасников или сторонней компании, которая аудит делает. Но всегда за это отвечал в первую очередь технический руководитель. И это нормально, ибо он лучше всех знает продукт, что там используется и какие решения могут представлять потенциальный вектор для атаки. Но если у вас этим отдельные люди занимаются, ну хорошо.
Потому что - это модно, молодежно) А автор статьи - питон-евангелист. Разве не чувствуете, как он взахлёб новые фичи перечисляет. Я некоторые предложения не до конца понял, так все быстро. Шучу конечно)
А если серьезно, то очень странно, что две основные причины, ради которых обычно затевается это часто недешевое для бизнеса удовольствие, в статье не упомянуты. Это безопасность и исправление критичных ошибок. Выше уже написали про безопасность, security patches, уязвимости и вот это все. Так же часто обновляют, чтобы закрыть баги или какие-то вещи, которые работают не совсем, как должны или доставляют неудобства пользователям продукта или разработчикам. Ну и обновляться нужно своевременно, чтобы не получилось, как у автора комментария выше про больше месяца работы и много боли.
Статью надо было назвать вроде "Какие крутые вещи может предложить Python" или что-то в таком духе. А текущий заголовок и правда в статье не раскрыт.
Дак вот по удобству как раз большие вопросы, и я написал почему.
Очень часто большую часть времени в установке зависимостей занимает сборка какого-нибудь пакета из исходников, потому что нет готового бинарника под нужную архитектуру. А ту скорость, про которую написано в статье, вы будете ощущать только при установке окружения начисто с нуля, что происходит... ну пару раз за несколько месяцев? может... Так что самый большой плюс получают наверное те, кто постоянно устанавливает что-то и желательно с нуля.
Зато есть жирный минус, перекрывающий сомнительный "самый огромный" плюс - Платформозависимые lockfile. То есть, я либо использую для разработки и деплоя одну платформу, либо виртуализация, эмуляция и и иже с ними. Хотя даже питон сам по себе платформонезависимый, и собрать можно практически под любую архитектуру, и разрабатывать и запускатьь код в большинстве случаев без шаманства на разных архитектурах.
Так что я прям даже не знаю, я лучше заюзаю pdm или poetry. Не так быстро ставят, зато экономят время на разработку в целом без пляски с архитектурами.
Я даже знаю, почему не помогло. Это скорее всего потому, что каждый член команды считает своей обязанностью только свою задачу. Код ревью обычно не любят (и не хотят соответственно) делать и не считают это важным в работе. Отчасти, потому что это большинству неинтересно (интереснее код писать), отчасти, что обычно на это не планируют время явно. Эта проблема стара как мир. Чтобы заработало, надо создать условия.
Закладывайте время для код ревью при планировании.
Донесите до людей, что их обязанность не только код писать по своей задаче, а ещё помогать чужим задачам быть доставленными конечному клиенту. А для этого они должны делать ревью, которое на них назначили. Это должна быть общая ответственность за доставку. Каждый разработчик должен понимать, что просто написанный и отправленный на ревью код != завершенная задача != профит для компании != за что они получают деньги. Основная цель - решить проблему клиента. А этого сделать не получится, если код не доставлен клиенту,. А без ревью доставить не получится.
Спросите, что нужно поменять в работе, чтобы это было реально и удобно для них. Поменяйте процессы соответственно.
Но опять же, это должен делать руководитель, а не вы. Но вы пытались решить проблему своим способом, как можете. Если в данном случае это помогло, то ок. Но это как лечить зубы полосканием солёной водой вместо похода к стоматологу. Изначальная проблема в другой плоскости.
Ещё может быть такое, что они просто меньше времени тратят на ревью. Раньше смотрели более тщательно. Теперь пробежались быстро, поставили аппув и все. От этого может страдать качество задач, а может и не страдать. Зависит от опытности людей в команде. Главное, чтобы все были довольны. Если у вас все хорошо, значит вы делаете правильные вещи.
Ну ок. Что очень странно. У вас люди теперь больше времени тратят на ревью, да ещё на переключение контекста, но общие метрики остались такими ми же. Вы же 8 часовой рабочий день не увеличивали? Ну тогда откуда взялось дополнительное время? Ребята перерабатывают теперь? Или раньше не дорабатывали?)
Вообще, подозреваю, что проблема у вас просто в том, что разработчики не хотят настраивать уведомления и фильтры в почте. Когда сыплется много всего, естественно это превращается в шум и никто на это не обращает внимания. Поэтому ваши уведомления на почту неэффективны. Решается это на управленческом уровне донесением знаний до команды, как это настроить и каждому индивидуально помогать, если человек сам не может сделать уведомления эффективными. Но конечно, это должен делать руководитель, а не вы, это его прямая обязанность - настроить процессы работы команды наиболее эффективно.
А ваши метрики вполне естественно показывают рост, потому что разработчики обращают внимание на сообщения бота. Но ваши метрики надо рассматривать вкупе с метриками общей продуктивности команды. И скорее всего там убыло. Как раз из-за дополнительного времени на переключение контекста.
А так ли прям срочно человек должен все бросать и бежать делать ревью, как только приходит сообщение? Обычно разработчики погружены в контекст решаемой задачи и редко кто готов все бросить и сию же минуту переключиться на ревью. А не любят они это делать часто и срочно потому, что переключение контекста затратно и контрпродуктивно, особенно при решении сложных и нетривиальных задач. А чтобы сделать ревью качественно, а не абы как, нужно иногда потратить больше 10 минут и даже разобраться в контексте сделанных изменений.
Я могу поделиться, как у меня ребята решают эту, прямо скажем не новую и уникальную, проблему. Достаточно взять за привычку каждое утро начинать с ревью задач. Так и контекст переключать не надо, и со свежей головой разбираться в чужом коде намного эффективнее получается. И не надо писать бота.и потом и его ещё поддерживать. Но конечно, ситуации бывают разные. Если у вас вечный аврал и нужно часто что-то ревьюить в течение дня и деплоить несколько раз за день, то вариант с чатом будет эффективнее.
На мой взгляд проблема организационная, а вы пытаетесь решить её техническим способом. Тут уже заметили в комментариях, что любая более-менее зрелая система, в которой есть возможность делать код ревью, имеет систему уведомлений. Вы бы лучше написали, почему эта система в вашем случае не работала. Вот отсюда и надо начинать решение.
Я имел ввиду задачи, которые закрывают люди, которых вы набираете, а не вы сами.
Да на самом деле неважно, какие конкретно задачи. Любую задачу можно сделать так, что вроде как задача и готова, исполнитель ее закрыл, а по факту сделана некачественно. И это выясняется в процессе эксплуатации, и не факт что сразу.
Я очень рад за вас, если ваши исполнители все делают качественно и в срок и никогда не косячят. Но это не значит, что везде такие же задачи, как у вас и такие же бравые ребята. И контроль качества в любом деле лишним не бывает, а иногда и жизненно необходим.
Если ваша метрика продуктивности опирается только на количество сделанных задач, то это так себе метрика. В моей практике были люди, которые задачи пачками закрывали. Только за ними потом приходилось переделывать, потому что задача либо не покрывала все требования, либо кучу нюансов не учитывала, а иногда и работала через раз. Без метрики качества и ее отслеживания во времени кол-во закрытых задач - такой себе показатель.
А откуда у вас такая статистика?)) Общемировой тренд как раз таки другой - увеличение возраста родителей до появления первого ребенка. Причиной тому желание построить карьеру, пока молодой, увеличение продолжительности жизни, больше возможностей для женщины не зависеть от мужчины и семьи и ещё много других мелких. Поэтому люди могут заводить первого ребенка и в 30 и позже. А в таком возрасте специалист уже может дорасти и до уровня сеньера. Ну и не все останавливаются на 1 ребенке, у меня например 2 и третий на подходе. А я уже который год работаю на руководящей позиции. У многих моих знакомых от двух детей, и их больше, чем тех, у кого один.
Наличие маленьких детей редко коррелирует с уровнем профессионализма) Может быть конечно сеньер чуть лучше работает с постоянно отвлекающими и орущими детьми, но вряд ли разница сильно заметна. В обоих случаях получается хуже, чем без отвлекающих факторов.
Ну если лично у вас таких проблем не было, это не значит, что их не существует. Это лишь говорит о том, что вы с ними не сталкивались. А я сталкивался и докер эту проблему отлично решает. И ещё много других. Не стоит судить от полезности инструмента только лишь по применимости или не применимости именно в вашей работе. Это как минимум не репрезентативно. Если для вас это избыточная абстракция - замечательно. Но для тех, кто его использует для решения своих задач - это полезный рабочий инструмент.
Докер унифицирует среду выполнения и процесс сборки и запуска в ней. Это значительно исключает ситуацию бага и разработчика, у которого "все работает локально, ничего не знаю", а там оказывается версии библиотеки в ОС у разраба и на сервере разные. Так что зря вы на докер катите. Это одна из хороших практик и необходимость, нежели переусложнение. Вдобавок докер изолирует все зависимости от системы, и у вас исключается ситуация, когда один проект требует одну версию интерпретатора/компилятора и версии библиотек в системе, а другой -другие, а третий - третьи. И как вы все это будете устанавливать и обслуживать на одной машине без изоляции - большой вопрос и отдельная очень "интересная" тема.
Версии то есть в апи, только вот если у вас много внешних потребителей этого апи, на которых вам сложно повлиять, то заставить их переползти на новую версию может быть очень не быстро. Ибо доп. затраты для компании-партнёра, а профит не очевиден, итак же все работает. Так что с версиями надо быть аккуратнее и делать по возможности без них, либо с минимальным из количеством. А то может случиться, что поддерживать их придётся если не вечно, то очень долго.
Этого вполне можно добиться, если конфигурация проекта локально отличается от конфигурации на сервере. Например, фиче-флаги выставлены по-другому. С этим надо быть аккуратнее))
Это вы меня извините) На моей практике изменение именно апи слоя не вызывало каких-то серьезных затрат. Значительное время обычно занимала как раз изменение логики работы с апи и подготовки данных запроса и ответа. Поэтому название статьи интерпретировал не так, как вы задумыаали.