В таком случае hotfix-ы можно раскатывать делая hotfix-ветку от master, а потом сливая обратно в develop. Но, полагаю, вы уже так и делаете.
А от develop в вашем случае да, не избавиться.
Если принимаете советы, то я бы посоветовал вам вот что сделать:
Оцените дизайн ваших микросервисов. Тот факт, что вам приходится ради одной задачи менять сразу несколько сервисов намекает на то, что сервисы распилены не очень удачно и кодовые базы у сервисов разделены, но связность между ними осталась высокой.
Оцените, действительно ли сервисы надо катить вместе или можно выкатывать каждый отдельно, сохраняя рабочим прежний контракт. Версионирование API и contract testing тут могут сильно помочь.
Посмотрите, возможно вам будет проще если переехать в монорепозиторий. Решение специфическое, но в некоторых случаях полезное.
У нас (теперь) нет спринтов и мы просто катим задачу на прод как только она готова. Ну или закрываем feature flag-ом и все равно катим, но такое бывает довольно редко. В такой схеме в develop, как в буфере перед релизом, просто нет необходимости. Сделали - релизим, стараемся в continuous delivery.
Если у вас 10 задач должны ехать на прод вместе, то, вероятно, мы с вами просто по-разному делим на задачи. У нас задача это либо цельный кусок ценности для пользователя (который уже довольно автономен по определению), либо как раз отдельно деплоящийся кусок технической работы (тоже автономный по определению). Поэтому связки на такое количество задач, как вы описали, у нас просто не возникает. У нас даже на 2 задачи связка это большая редкость.
Если вы расскажете, что у вас под задачей понимается, то я, вероятно, смогу на ваш вопрос полностью ответить.
Замечания справедливы, но для меня они не списывают ценность исследования в ноль.
Проблема представительности свойственна любым большим исследованиям. Но какие есть разумные альтернативы?
По поводу "корреляция не значит каузация" - это верно. Но есть ли (и возможны ли) исследования, подтверждающие причинно-следственную связь, а не корреляцию, для качественных показателей, тем более в таких сложных процессах, как разработка ПО?
По такой логике все исследования вроде уровня безопасности, образованности населения, социальной справедливости, уровня коррупции, индекса счастья, потребительских ожиданий - бесполезны.
Для меня все это поводы не воспринимать результаты исследования как догму и продолжать думать своей головой. Но не повод отбросить результаты как бесполезные.
Принимать решения имея в арсенале цифры+ориентиры+собственный опыт это лучше, чем принимать решения, имея только собственный опыт.
А вы можете более развёрнуто рассказать, в чем некорректность исследования? Ну или ссылкой поделиться.
По поводу модели бранчевания как главной причины - не совсем. Главным изменением было снятие избыточной нагрузки на e2e-тесты, как на главный bottleneck.
Ну и касательно очевидности. Вы знаете, когда все позади, и когда мы говорим только о применённом решении, то и правда кажется очевидным. Но так не было "внутри событий". У этого феномена даже отдельное название есть - hindsight bias, это одно из когнитивных искажений. Из-за него же человечество никогда не увидит объективных учебников истории, например.
Когда находишься внутри событий и у тебя прод разваливается, тесты флакуют, кучи legacy кода, задачи горят, люди горят, то лишняя ветка совсем не кажется важной :) Я уж не говорю о том, что я команду уговорил от этой ветки отказаться не с первого раза.
И вот тут как раз DORA-метрики и спасают, потому что они помогают в нужную сторону посмотреть, найти за какую ниточку начать вытягивать. И найти общий язык с окружением, чтобы за нужную ниточку всем вместе и потянуть.
Да, это арифметика по рабочему времени. Пайплайн, конечно, можно запустить и ночью. Но в изначальной реализации это мало помогало. Во-первых, тесты часто падали. Во-вторых, как я писал в статье, e2e-тесты можно запустить только одни за раз. А у билдов в CI таймауты настроены. Поэтому, запустив вечером 14 сборок сервисов, утром прийти и увидеть их все прошедшими было не очень-то реально.
Я показывал эти метрики нашему CTO и нашему CEO (по сути статья написана из материалов, которые я показывал им). Оба ответили, что ценность качественного конвейера поставки теперь очевидна и дали добро на дальнейшие работы по его прокачке.
Когда мы начали поставлять без факапов, перестали срывать сроки и порешали проблемы, до которых раньше просто не доходили руки - а всего этого мы добились - бизнес это еще как оценил. А с цифрами метрик еще и понятно где мы сейчас, а куда можем прийти если приложим еще усилия.
И, например, security упомянутый в статье, и до которого мы раньше никак не могли добраться, имеет вполне материальное выражение. Внешние аудиторы выставляют security rating нашей компании и это:
Имидж нашего продукта перед клиентами
Имидж компании перед инвесторами
Прямое влияние на стоимость страховки от security-рисков.
Для меня киллер-фичей стала проверка на совместимость лицензий зависимостей, используемых на проекте, с заданными политиками. Также умеет агрегировать репорты от других анализаторов.
Спасибо. Я писал статью именно с надеждой снизить размытость темы.
>Статья описывает качества идеального работника для работодателя, но не для самого работника.
Статья разбирает пример с решением "win-win", чтобы не разжигать. Пример может быть другим, с личностный конфликтом и рациональным решением "уволюсь". Но качества, необходимые для принятия осознанного решения вместо эмоций или пассивного бездействия, остаются те же - рефлексия, осознанность, ответственность.
Яростно плюсую, что на таких ситуациях можно здоровье потерять - у самого такой опыт есть. Но вот на вопрос:
Почему я, добросовестно отрабатывая свои 40 часов в неделю испытываю стресс, чувство долга и чувство, что я кого-то подвел?
Я решил менять не компании, а свое отношение к стрессу. Потому что видел руководителей, основателей стартапов и собственников бизнеса у которых нагрузка гораздо выше моей, но они почему-то не сгорали.
Вместо того, чтобы искать компанию с хорошими процессами, можно научиться их создавать. И я постепенно понял, что стрессоустойчивость это не про то, кто крепче всех сжал челюсти и пашет. Это про умение не вовлекаться в проблему лично, но спокойно и методично выстраивать те самые бизнес-процессы и культуру работы в компании.
Ведь хорошие бизнес-процессы и культура в компаниях сами собой не появляются. Их создают сотрудники, и в том числе тимлиды. И моя статья это опыт создания таких процессов и культуры. Все здесь описанное, это вместо 80-часовой недели и стресса, а не вдобавок к ним.
Это скорее не плохое, а просто имеющаяся реальность.
Никто не хочет лечиться у неопытного врача, отдавать ребенка неопытному преподавателю, нанимать на атомную станцию неопытного физика-ядерщика :)
Но, чтобы у нас были опытные специалисты, им нужно где-то получать опыт. Поэтому важно делиться своими знаниями с теми, кому они нужны, и оказывать поддержку новичкам. Другого пути я не вижу.
Мне кажется, мы с вами пишем об одной и той же проблеме.
"пытались починить все понемногу" - это как раз распыление, от которого я предостерегаю. За один раз надо решать одну проблему, но решать ее качественно, в идеале до конца.
"незавершенный рефакторинг делал код зачастую еще более дурнопахнущим" - а это как раз недовернутый цикл Деминга. Не закончили, отвлеклись, и вот у нас +1 долг.
Абсолютно согласен. Коллег не нужно "спасать" - вокруг люди взрослые и умные, сами все умеют. Смысл совета в том, чтобы подтолкнуть к открытому разговору того, кто видит проблему, но, например, стесняется ее обозначить. То есть просто "сделать первый шаг".
Но если запроса на твою помощь нет - просто устранись. И искать проблемы там, где их нет, конечно, тоже не стоит.
Это просто отличный вопрос, спасибо за него. Опыт есть, но очень разносторонний.
— В провалившихся переменах далеко не всегда виноват кто-то конкретный. Внедрение изменений в организациях это очень сложно и это отдельная большая ветвь менеджмента, полная психологии, системного анализа и т.п. Можно начать с гугления «change leadership», «change management», «change agent». Единого, достойного, бесплатного источника знаний не могу посоветовать, поскольку сам такой не нашел.
— Попробовать найти «спонсора изменений» — руководителя с достаточной властью для принятия решений и реально заинтереснованного в изменениях, которые вы предлагаете. Но в некоторых компаниях «объезд» непосредственного руководителя может к политическим игрищам привести.
— Есть простая мантра «Нет стрессора — нет изменений». Это из основ change leadership как раз идея. Иногда этот стрессор нужно создавать искусственно. Но это тоже, конечно, аккуратно и обдуманно.
Согласен и дополню, что техлидов лучше не один, а по одному на каждые 3-6 человек в команде. Без этого очень тяжело поддерживать коммуникации в большой команде.
Тимлид — за стратегию и people management. Техлиды — за тактику и глубоко в теме по технике/архитектуре.
У нас такой подход к организации команд.
Начав с похожих соображений я нашёл для себя идеальным Planyway. Он работает поверх Trello + интегрируется с календарями.
В Trello задачи. В корпоративном Outlook рабочие встречи. В Google календаре личные встречи, напоминания о днях рождения и т.д. А в Planyway на одном экране видишь все.
Плюс задачам из трелло можно длительность задавать, в виде таймлайна все вместе смотреть и т.д.
VS Code действительно быстро развивается, но как редактор общего назначения, годный для всего подряд, неспециализированный.
Любая «заточка» его под конкретные нужды (тот же C#) делается через расширения. Такая модель имеет ограничения, потому что правила игры определяет сам редактор кода и они должны оставаться универсальными, подходить всем плагинам.
Скорее всего, мы никогда не увидим такие возможности анализа, рефакторинга, автоисправлений, контекстных действий как в Rider и в той же Visual studio. А также штуки вроде дизайнеров DbContext-ов и прочие.
Полагаю, что все больше функционала будет перекочевывать в консоль. В dotnet CLI уже есть шаблоны проектов, работа с зависимостями, сборка, тесты, публикация, запуск — все через консоль вместо кнопок на UI.
И полноценным IDE в этих условиях всегда будет место и на них будет спрос. И, скорее всего, они так и будут платными именно за свою оптимальность и продуманность для конкретных задач.
Мой комментарий про разработку, а не про конечный хостинг.
Но про перфоманс очень интересно. Можете поделиться ссылкой на сравнения? Я даже не в курсе, что с перфомансом .Net на Linux есть серьёзные проблемы.
Вы знаете, ответ на этот вопрос почти философский и сугубое имхо.
У меня за время работы в индустрии сложилась примерная такая картина:
Изначально была куча технологий, и вокруг каждой было свое сообщество, которое самостоятельно развивало свою экосистему.
Дальше активное развитие получил open source. И уже не просто библиотечки, а огромные инструменты. Те же Google и Netflix сделали гигантский вклад в инструменты continuous delivery. И множество сообществ объединилось вокруг этих инструментов. На мой взгляд, объединились уже все, а Microsoft-сообщество (не сам Microsoft, а его сообщество) стоит несколько в сторонке и за проприетарные инструменты держится: Visual Studio, Powershell, Azure DevOps, SQL Server, и, конечно, Windows.
Еще можно на Cloud Native Landscape посмотреть. В каждой категории множество инструментов, альтернатив. В большинстве бесплатное и open source Но, если отфильтровать по Microsoft, то останется совсем немного и все прямо или опосредовано (через Azure) платное. Я тут оговорюсь — я совершенно не против чтобы Microsoft зарабатывал, тем более что многие из его инструментов действительно отличные. Но один и платный инструмент, привязанный к экосистиеме — это ограничение. И сам же Microsoft все больше вливается в общий движняк. Linux уже не только в Azure живет, но и WSL прямо в Windows работает. А недавно Microsoft объявил, что Windows для них больше не стратегический продукт и его роль в бизнесе компании будет снижаться.
Если Microsoft таким путем идет, то и разработчикам, на мой взгляд, стоит в ту же сторону посмотреть, а не позади плестись.
Второй момент заключается в том, что некоторые важные вещи на Linux просто лучше работают (контейнеры). Также нередко какая-нибудь open source библиотека (во фронтенд разработке спотыкался об это не раз и не два) полезная, хочешь фичу запилить. Но на windows ни собрать, ни тесты запустить не можешь. Потому что разработчики на Linux/Mac сидят и тулинг у них свой. А для тебя Linux это барьер.
И третий момент заключается в том, что выучить новый язык программирования, например, python или scala, чаще всего совсем нетрудно. На это нужно буквально пару недель. Ну ладно, чтобы неплохо освоиться — пара месяцев. Но вот ты узнал новый язык, он тебе понравился и это твое. Устраиваешься в классный стартап. Но Scala-то-Scala а работают там в линухах, на bash, глубоко знают весь тулинг. А с этим уже не так просто освоиться и быстро начать продуктивно работать. У меня вот вообще был такой эффект, что я в Rider первые месяцы не мог делать действительно сложные задачи. UI непривычный, цветовые схемы, шрифты — внимание постоянно на них отвлекается и я не могу работать на пике. Кастомные темы цветовые перебирал — без толку. Просто со временем привык, но это время понадобилось.
В общем, главный барьер это не язык, а тулинг. И я не вижу причин не перескочить этот барьер и не влиться в большое, единое, в основном бесплатное и open source сообщество да еще и повысить свою востребованность на рынке труда. Тем более что и Microsoft уже вовсю поддерживает Linux.
Сейчас у меня стоят параллельно Ubuntu и Windows и я спокойно осваиваюсь. Изначально старался работать в Ubuntu, если уперся в незнание — перескочил на винду и продуктивность по текущей работе не теряю. А нужные знания позже подтягиваю. На текущий момент на Ubuntu работать уже банально удобнее.
Понял.
В таком случае hotfix-ы можно раскатывать делая hotfix-ветку от master, а потом сливая обратно в develop. Но, полагаю, вы уже так и делаете.
А от develop в вашем случае да, не избавиться.
Если принимаете советы, то я бы посоветовал вам вот что сделать:
Оцените дизайн ваших микросервисов. Тот факт, что вам приходится ради одной задачи менять сразу несколько сервисов намекает на то, что сервисы распилены не очень удачно и кодовые базы у сервисов разделены, но связность между ними осталась высокой.
Оцените, действительно ли сервисы надо катить вместе или можно выкатывать каждый отдельно, сохраняя рабочим прежний контракт. Версионирование API и contract testing тут могут сильно помочь.
Посмотрите, возможно вам будет проще если переехать в монорепозиторий. Решение специфическое, но в некоторых случаях полезное.
У нас (теперь) нет спринтов и мы просто катим задачу на прод как только она готова. Ну или закрываем feature flag-ом и все равно катим, но такое бывает довольно редко. В такой схеме в develop, как в буфере перед релизом, просто нет необходимости. Сделали - релизим, стараемся в continuous delivery.
Если у вас 10 задач должны ехать на прод вместе, то, вероятно, мы с вами просто по-разному делим на задачи. У нас задача это либо цельный кусок ценности для пользователя (который уже довольно автономен по определению), либо как раз отдельно деплоящийся кусок технической работы (тоже автономный по определению). Поэтому связки на такое количество задач, как вы описали, у нас просто не возникает. У нас даже на 2 задачи связка это большая редкость.
Если вы расскажете, что у вас под задачей понимается, то я, вероятно, смогу на ваш вопрос полностью ответить.
Замечания справедливы, но для меня они не списывают ценность исследования в ноль.
Проблема представительности свойственна любым большим исследованиям. Но какие есть разумные альтернативы?
По поводу "корреляция не значит каузация" - это верно. Но есть ли (и возможны ли) исследования, подтверждающие причинно-следственную связь, а не корреляцию, для качественных показателей, тем более в таких сложных процессах, как разработка ПО?
По такой логике все исследования вроде уровня безопасности, образованности населения, социальной справедливости, уровня коррупции, индекса счастья, потребительских ожиданий - бесполезны.
Для меня все это поводы не воспринимать результаты исследования как догму и продолжать думать своей головой. Но не повод отбросить результаты как бесполезные.
Принимать решения имея в арсенале цифры+ориентиры+собственный опыт это лучше, чем принимать решения, имея только собственный опыт.
А вы можете более развёрнуто рассказать, в чем некорректность исследования? Ну или ссылкой поделиться.
По поводу модели бранчевания как главной причины - не совсем. Главным изменением было снятие избыточной нагрузки на e2e-тесты, как на главный bottleneck.
Ну и касательно очевидности. Вы знаете, когда все позади, и когда мы говорим только о применённом решении, то и правда кажется очевидным. Но так не было "внутри событий". У этого феномена даже отдельное название есть - hindsight bias, это одно из когнитивных искажений. Из-за него же человечество никогда не увидит объективных учебников истории, например.
Когда находишься внутри событий и у тебя прод разваливается, тесты флакуют, кучи legacy кода, задачи горят, люди горят, то лишняя ветка совсем не кажется важной :) Я уж не говорю о том, что я команду уговорил от этой ветки отказаться не с первого раза.
И вот тут как раз DORA-метрики и спасают, потому что они помогают в нужную сторону посмотреть, найти за какую ниточку начать вытягивать. И найти общий язык с окружением, чтобы за нужную ниточку всем вместе и потянуть.
Да, это арифметика по рабочему времени. Пайплайн, конечно, можно запустить и ночью. Но в изначальной реализации это мало помогало. Во-первых, тесты часто падали. Во-вторых, как я писал в статье, e2e-тесты можно запустить только одни за раз. А у билдов в CI таймауты настроены. Поэтому, запустив вечером 14 сборок сервисов, утром прийти и увидеть их все прошедшими было не очень-то реально.
Я показывал эти метрики нашему CTO и нашему CEO (по сути статья написана из материалов, которые я показывал им). Оба ответили, что ценность качественного конвейера поставки теперь очевидна и дали добро на дальнейшие работы по его прокачке.
Когда мы начали поставлять без факапов, перестали срывать сроки и порешали проблемы, до которых раньше просто не доходили руки - а всего этого мы добились - бизнес это еще как оценил. А с цифрами метрик еще и понятно где мы сейчас, а куда можем прийти если приложим еще усилия.
И, например, security упомянутый в статье, и до которого мы раньше никак не могли добраться, имеет вполне материальное выражение. Внешние аудиторы выставляют security rating нашей компании и это:
Имидж нашего продукта перед клиентами
Имидж компании перед инвесторами
Прямое влияние на стоимость страховки от security-рисков.
Из свежих и интересных ещё стоит упомянуть Qodana от Jetbrains.
Для меня киллер-фичей стала проверка на совместимость лицензий зависимостей, используемых на проекте, с заданными политиками. Также умеет агрегировать репорты от других анализаторов.
Спасибо. Я писал статью именно с надеждой снизить размытость темы.
>Статья описывает качества идеального работника для работодателя, но не для самого работника.
Статья разбирает пример с решением "win-win", чтобы не разжигать. Пример может быть другим, с личностный конфликтом и рациональным решением "уволюсь". Но качества, необходимые для принятия осознанного решения вместо эмоций или пассивного бездействия, остаются те же - рефлексия, осознанность, ответственность.
Яростно плюсую, что на таких ситуациях можно здоровье потерять - у самого такой опыт есть. Но вот на вопрос:
Почему я, добросовестно отрабатывая свои 40 часов в неделю испытываю стресс, чувство долга и чувство, что я кого-то подвел?
Я решил менять не компании, а свое отношение к стрессу. Потому что видел руководителей, основателей стартапов и собственников бизнеса у которых нагрузка гораздо выше моей, но они почему-то не сгорали.
Вместо того, чтобы искать компанию с хорошими процессами, можно научиться их создавать. И я постепенно понял, что стрессоустойчивость это не про то, кто крепче всех сжал челюсти и пашет. Это про умение не вовлекаться в проблему лично, но спокойно и методично выстраивать те самые бизнес-процессы и культуру работы в компании.
Ведь хорошие бизнес-процессы и культура в компаниях сами собой не появляются. Их создают сотрудники, и в том числе тимлиды. И моя статья это опыт создания таких процессов и культуры. Все здесь описанное, это вместо 80-часовой недели и стресса, а не вдобавок к ним.
Это скорее не плохое, а просто имеющаяся реальность.
Никто не хочет лечиться у неопытного врача, отдавать ребенка неопытному преподавателю, нанимать на атомную станцию неопытного физика-ядерщика :)
Но, чтобы у нас были опытные специалисты, им нужно где-то получать опыт. Поэтому важно делиться своими знаниями с теми, кому они нужны, и оказывать поддержку новичкам. Другого пути я не вижу.
Мне кажется, мы с вами пишем об одной и той же проблеме.
"пытались починить все понемногу" - это как раз распыление, от которого я предостерегаю. За один раз надо решать одну проблему, но решать ее качественно, в идеале до конца.
"незавершенный рефакторинг делал код зачастую еще более дурнопахнущим" - а это как раз недовернутый цикл Деминга. Не закончили, отвлеклись, и вот у нас +1 долг.
Или я что-то неверно понял из вашего комментария?
Абсолютно согласен. Коллег не нужно "спасать" - вокруг люди взрослые и умные, сами все умеют. Смысл совета в том, чтобы подтолкнуть к открытому разговору того, кто видит проблему, но, например, стесняется ее обозначить. То есть просто "сделать первый шаг".
Но если запроса на твою помощь нет - просто устранись. И искать проблемы там, где их нет, конечно, тоже не стоит.
— В провалившихся переменах далеко не всегда виноват кто-то конкретный. Внедрение изменений в организациях это очень сложно и это отдельная большая ветвь менеджмента, полная психологии, системного анализа и т.п. Можно начать с гугления «change leadership», «change management», «change agent». Единого, достойного, бесплатного источника знаний не могу посоветовать, поскольку сам такой не нашел.
— Попробовать найти «спонсора изменений» — руководителя с достаточной властью для принятия решений и реально заинтереснованного в изменениях, которые вы предлагаете. Но в некоторых компаниях «объезд» непосредственного руководителя может к политическим игрищам привести.
— Есть простая мантра «Нет стрессора — нет изменений». Это из основ change leadership как раз идея. Иногда этот стрессор нужно создавать искусственно. Но это тоже, конечно, аккуратно и обдуманно.
Тимлид — за стратегию и people management. Техлиды — за тактику и глубоко в теме по технике/архитектуре.
У нас такой подход к организации команд.
Начав с похожих соображений я нашёл для себя идеальным Planyway. Он работает поверх Trello + интегрируется с календарями.
В Trello задачи. В корпоративном Outlook рабочие встречи. В Google календаре личные встречи, напоминания о днях рождения и т.д. А в Planyway на одном экране видишь все.
Плюс задачам из трелло можно длительность задавать, в виде таймлайна все вместе смотреть и т.д.
Тоже пользуюсь физическим таймером, с ним гораздо проще сконцентрироваться.
Недавно нашёл идеальный — он вместо звука может сигналить подсветкой. Идеально если работаешь в команде. Или если удаленка и дети спят.
Плюс двухрежимный. Можно настроить по таймеру на работу и на отдых и одной кнопкой запускать нужный.
Если кто-то в поисках подобного — на всем известном китайском сайте можно найти по запросу "timer ys-390"
Любая «заточка» его под конкретные нужды (тот же C#) делается через расширения. Такая модель имеет ограничения, потому что правила игры определяет сам редактор кода и они должны оставаться универсальными, подходить всем плагинам.
Скорее всего, мы никогда не увидим такие возможности анализа, рефакторинга, автоисправлений, контекстных действий как в Rider и в той же Visual studio. А также штуки вроде дизайнеров DbContext-ов и прочие.
Полагаю, что все больше функционала будет перекочевывать в консоль. В dotnet CLI уже есть шаблоны проектов, работа с зависимостями, сборка, тесты, публикация, запуск — все через консоль вместо кнопок на UI.
И полноценным IDE в этих условиях всегда будет место и на них будет спрос. И, скорее всего, они так и будут платными именно за свою оптимальность и продуманность для конкретных задач.
Мой комментарий про разработку, а не про конечный хостинг.
Но про перфоманс очень интересно. Можете поделиться ссылкой на сравнения? Я даже не в курсе, что с перфомансом .Net на Linux есть серьёзные проблемы.
У меня за время работы в индустрии сложилась примерная такая картина:
Изначально была куча технологий, и вокруг каждой было свое сообщество, которое самостоятельно развивало свою экосистему.
Дальше активное развитие получил open source. И уже не просто библиотечки, а огромные инструменты. Те же Google и Netflix сделали гигантский вклад в инструменты continuous delivery. И множество сообществ объединилось вокруг этих инструментов. На мой взгляд, объединились уже все, а Microsoft-сообщество (не сам Microsoft, а его сообщество) стоит несколько в сторонке и за проприетарные инструменты держится: Visual Studio, Powershell, Azure DevOps, SQL Server, и, конечно, Windows.
Еще можно на Cloud Native Landscape посмотреть. В каждой категории множество инструментов, альтернатив. В большинстве бесплатное и open source Но, если отфильтровать по Microsoft, то останется совсем немного и все прямо или опосредовано (через Azure) платное. Я тут оговорюсь — я совершенно не против чтобы Microsoft зарабатывал, тем более что многие из его инструментов действительно отличные. Но один и платный инструмент, привязанный к экосистиеме — это ограничение. И сам же Microsoft все больше вливается в общий движняк. Linux уже не только в Azure живет, но и WSL прямо в Windows работает. А недавно Microsoft объявил, что Windows для них больше не стратегический продукт и его роль в бизнесе компании будет снижаться.
Если Microsoft таким путем идет, то и разработчикам, на мой взгляд, стоит в ту же сторону посмотреть, а не позади плестись.
Второй момент заключается в том, что некоторые важные вещи на Linux просто лучше работают (контейнеры). Также нередко какая-нибудь open source библиотека (во фронтенд разработке спотыкался об это не раз и не два) полезная, хочешь фичу запилить. Но на windows ни собрать, ни тесты запустить не можешь. Потому что разработчики на Linux/Mac сидят и тулинг у них свой. А для тебя Linux это барьер.
И третий момент заключается в том, что выучить новый язык программирования, например, python или scala, чаще всего совсем нетрудно. На это нужно буквально пару недель. Ну ладно, чтобы неплохо освоиться — пара месяцев. Но вот ты узнал новый язык, он тебе понравился и это твое. Устраиваешься в классный стартап. Но Scala-то-Scala а работают там в линухах, на bash, глубоко знают весь тулинг. А с этим уже не так просто освоиться и быстро начать продуктивно работать. У меня вот вообще был такой эффект, что я в Rider первые месяцы не мог делать действительно сложные задачи. UI непривычный, цветовые схемы, шрифты — внимание постоянно на них отвлекается и я не могу работать на пике. Кастомные темы цветовые перебирал — без толку. Просто со временем привык, но это время понадобилось.
В общем, главный барьер это не язык, а тулинг. И я не вижу причин не перескочить этот барьер и не влиться в большое, единое, в основном бесплатное и open source сообщество да еще и повысить свою востребованность на рынке труда. Тем более что и Microsoft уже вовсю поддерживает Linux.
Сейчас у меня стоят параллельно Ubuntu и Windows и я спокойно осваиваюсь. Изначально старался работать в Ubuntu, если уперся в незнание — перескочил на винду и продуктивность по текущей работе не теряю. А нужные знания позже подтягиваю. На текущий момент на Ubuntu работать уже банально удобнее.