Забрать недоделанную задачу у коллеги и починить упавший сервер сломанный этим коллегой это разные ситуации.
Сломанную систему чинит тот кто сейчас на месте, вне зависимости от того, кто её сломал. Это считается нормальным.
Отнимать у коллеги задачу, это не нормально. Нормально это пойти к вашему общему руководителю и попросить его передать вам эту задачу. Задача будет всё равно сделана вами (компания заработает денег) и при этом сохраниться уважительное отношение в коллективе.
Открою вам секрет, даже нормальный человек может обидеться, если с ним себя ведут по хамски, не надо быть для этого снежинкой.
Нужно уточнить про чатики. В слаке и тимсе есть "комментарии". На уровне чатика сообщение одно, а внутри может быть оживлённая беседа. Это его очень сильно разгружает от спама. Если такой фичи нет, то как не старайся - а получится помойка.
Автоматизация это хорошо. Есть CI и тесты, код аккуратный.
Репозиторий с хуком, который не использует хуки это подозрительно.
Такая проверка в одиночку бесполезна. Обычно используют что-то крупное и к нему добавляют плагинов и просто скрипты. Было бы хорошо посмотреть, что из этого уже есть в ruff flake8 pylint. И может быть даже законтрибьютить в один из этих проектов. Без форматера и глобального линтера, ревью это ад.
Код аккуратный, но мне кажется регулярки это опасно. Закомментированный код с комментами может сломать их. (в ruff и flake8 есть на это управа https://docs.astral.sh/ruff/rules/#eradicate-era).
В выводе нет номера строки. IDE умеет читать пути в выводе на консоль и можно будет кликом перейти в нужное место. В GitHub есть аннотации, cпециально отформатированные логи превращаются в комментарии к коду. Даже не надо в лог CI глядеть.
Но реальность такова, что начальство часто экономит
Вот и вся культура :(
Мне кажется выжать из людей максимум или создать нормальные условия для работы это международная практика. Особеннсти страны конечно есть но они не решающие.
Я тоже в аутсорсе участвовал в обучении. Но основной проект был спокойным, обошлось без переработок.
Отбирать задачи у коллеги самостоятельно на мой взгляд некрасиво. Такое стоит делегировать менеджеру, пусть он будет плохим парнем, у него должность такая.
А вот давать конретные подсказки - нормально. На GitHub даже есть такая фича как suggestions, можно сделать "реквест на изменения" в PullRequest.
У меня есть опыт работы в разых странах. В России работал и в стартапе и в оутсорсе и контрактором в большом забугорном энтерпрайзе. Есть большая разница и в культуре и в стиле общения и в способе решения проблем. Про геймдев часто говорять, что это токсичная атмосфера с переработками и низкими зарплатами, так что возможно свой мир со своими погремушками. Мне кажется часть вашего опыта специфичка именно к типу команий где вы работали.
Ага, так и хочется прямо читать этот сплошной "Спам", отвлекаясь от работы - перемешку мемов, обсуждений кто где кофе пошел попить, и "гениальных" идей вне доски задач
Вопрос культуры в команде.
У нас в команде не такой уж и сплошной "Спам". Рабочих сообщений больше чем развлекательных. А еще есть ретро, где анонимно можно поднять проблему, если она волнует. Есть 1:1 с лидом, где можно обсудить проблемы.
Сам неоднократно сталкивался с тем, когда тебе накидывают "учеников", без учета твоей основной работы, а потом бывает, что "ученики" еще и приходят на тебя жаловаться, что ты не отвечаешь часами, пытаясь свою работу делать, а не решать чужие проблемы, которые вне планов
Посторяемость одной и той-же проблемы это признак плохого процесса. Либы вы говорите не с тем человеком, либо это кому-то выгодно.
Предположем я по ошибке добавил ваш номер. Сonstraints не ругаются. Терерь вы пробуете ввести свой номер. Сonstraints вам этого сделать не дадут.
Переименование первичного ключа, это не та фича которая идёт в большинстве сервисов из коробки. А если есть интеграции с внешними системами и ключ расползся по другим базам, то будет совсем весело.
Например, для метода getDocsByOrgRegionRequest я перепутал порядок и сначала у меня стоял subsystemType, а затем orgRegion и сервер выдавал ошибку несоответствия запросу интеграционной схеме. Пример правильного xml файла для этого метода:
У вас есть схема, значит в процессе разработки можно включить валидацию по схеме, чтобы не было сюрпризов в ответах. А еще лучше сразу тест на это накидать. Это экономит время на стадии разработки.
У Polars есть один большой плюс, важный в больщих системах. У неё НЕТ ЗАВИСИМОСТЕЙ!
Сложных системах, где используется много разных инструментов для датасаенса, начинается цирк с коням, так как очень многие зависять от numpy определённых версий.
Другими словами, если вы хотите использовать новыю версию библиотеки, может понадобиться апгрейдить практически все зависимости в системе.
Традиционное.
Не думаю, что этот ярлык здесь к месту. Такие люди есть в каждом покалении. И в любом покалении это будет меньшенство.
Если в компании есть культура (не на словах а на деле), то такие люди перевоспитываются.
Забрать недоделанную задачу у коллеги и починить упавший сервер сломанный этим коллегой это разные ситуации.
Сломанную систему чинит тот кто сейчас на месте, вне зависимости от того, кто её сломал. Это считается нормальным.
Отнимать у коллеги задачу, это не нормально. Нормально это пойти к вашему общему руководителю и попросить его передать вам эту задачу. Задача будет всё равно сделана вами (компания заработает денег) и при этом сохраниться уважительное отношение в коллективе.
Открою вам секрет, даже нормальный человек может обидеться, если с ним себя ведут по хамски, не надо быть для этого снежинкой.
Возможно вы плавали не с той командой.
В оригинальном пример рассматривался случай, когда фичу еще не выкатили. Починка сломанной системы это другой кейс.
Нужно уточнить про чатики. В слаке и тимсе есть "комментарии". На уровне чатика сообщение одно, а внутри может быть оживлённая беседа. Это его очень сильно разгружает от спама. Если такой фичи нет, то как не старайся - а получится помойка.
Не сталкивался с таким, только тесты в документации.
Пайтест еще умеет ранить из текстовых файлов.
https://docs.pytest.org/en/stable/how-to/doctest.html#how-to-run-doctests
Автоматизация это хорошо. Есть CI и тесты, код аккуратный.
Репозиторий с хуком, который не использует хуки это подозрительно.
Такая проверка в одиночку бесполезна. Обычно используют что-то крупное и к нему добавляют плагинов и просто скрипты. Было бы хорошо посмотреть, что из этого уже есть в ruff flake8 pylint. И может быть даже законтрибьютить в один из этих проектов. Без форматера и глобального линтера, ревью это ад.
Код аккуратный, но мне кажется регулярки это опасно. Закомментированный код с комментами может сломать их. (в ruff и flake8 есть на это управа https://docs.astral.sh/ruff/rules/#eradicate-era).
В выводе нет номера строки. IDE умеет читать пути в выводе на консоль и можно будет кликом перейти в нужное место. В GitHub есть аннотации, cпециально отформатированные логи превращаются в комментарии к коду. Даже не надо в лог CI глядеть.
И еще реже о том что этим кто-то будем мы сами через некоторое время.
Вот и вся культура :(
Мне кажется выжать из людей максимум или создать нормальные условия для работы это международная практика. Особеннсти страны конечно есть но они не решающие.
Я тоже в аутсорсе участвовал в обучении. Но основной проект был спокойным, обошлось без переработок.
Отбирать задачи у коллеги самостоятельно на мой взгляд некрасиво. Такое стоит делегировать менеджеру, пусть он будет плохим парнем, у него должность такая.
А вот давать конретные подсказки - нормально. На GitHub даже есть такая фича как suggestions, можно сделать "реквест на изменения" в PullRequest.
У меня есть опыт работы в разых странах. В России работал и в стартапе и в оутсорсе и контрактором в большом забугорном энтерпрайзе.
Есть большая разница и в культуре и в стиле общения и в способе решения проблем. Про геймдев часто говорять, что это токсичная атмосфера с переработками и низкими зарплатами, так что возможно свой мир со своими погремушками. Мне кажется часть вашего опыта специфичка именно к типу команий где вы работали.
Может просто нормативы по успеваемости?
Вопрос культуры в команде.
У нас в команде не такой уж и сплошной "Спам". Рабочих сообщений больше чем развлекательных. А еще есть ретро, где анонимно можно поднять проблему, если она волнует. Есть 1:1 с лидом, где можно обсудить проблемы.
Посторяемость одной и той-же проблемы это признак плохого процесса. Либы вы говорите не с тем человеком, либо это кому-то выгодно.
Предположем я по ошибке добавил ваш номер. Сonstraints не ругаются.
Терерь вы пробуете ввести свой номер. Сonstraints вам этого сделать не дадут.
Переименование первичного ключа, это не та фича которая идёт в большинстве сервисов из коробки. А если есть интеграции с внешними системами и ключ расползся по другим базам, то будет совсем весело.
Из стрима в файл переливать лучше по кусочкам. А вдруг файл больше чем память?
гляньте на https://docs.python.org/3/library/shutil.html#shutil.copyfileobj
У вас есть схема, значит в процессе разработки можно включить валидацию по схеме, чтобы не было сюрпризов в ответах. А еще лучше сразу тест на это накидать. Это экономит время на стадии разработки.
Последний раз про SOAP вспоминал в этом ролике.
https://www.youtube.com/watch?v=gR1PujzQ53Q
У Polars есть один большой плюс, важный в больщих системах. У неё НЕТ ЗАВИСИМОСТЕЙ!
Сложных системах, где используется много разных инструментов для датасаенса, начинается цирк с коням, так как очень многие зависять от numpy определённых версий.
Другими словами, если вы хотите использовать новыю версию библиотеки, может понадобиться апгрейдить практически все зависимости в системе.
В некоторых случаях можно достигнуть хорошего ускорения используя --resolution lowest (https://docs.astral.sh/uv/concepts/resolution/#resolution-strategy). Если у все в логах много скачиваний разных версий одного и того-же пакета в поиске подходящей версии.
Это не его сервис, он с ними интегрируется. Далеко не везде можно вот так прийти и поменять чужой сервис.