Тёмная сторона работы в Яндекс.Маркете

    Я уволился из Яндекс.Маркета, отработав там почти 15 месяцев. Сегодня я хочу поделиться своим взглядом на работу в Яндекс.Маркете и рассказать о причинах ухода.


    Disclaimer: эта статья бесполезна для тех, кто работает или работал в Маркете; она предназначена в первую очередь для тех, кто лишь планирует туда пойти. А ещё Яндекс.Маркет – это не Яндекс, но очень близко. Поэтому всё, о чём я буду говорить, в первую очередь относится к Маркету, но значительная часть из этого точно так же может быть применена к большому Яндексу.


    Я ни в коем случае не претендую на объективность, это моё личное мнение.


    Я никого не отговариваю от трудоустройства в Яндекс. Наоборот, это отличный вызов для любого разработчика и, если вы в состоянии попасть в Компанию, то вам однозначно стоит попробовать.


    Моей главной проблемой стали завышенные ожидания. Я наивно полагал, что Яндекс как-то значимо отличается от других работодателей. Увы, большой разницы я не увидел.



    Релокация


    Я приехал в Яндекс.Маркет, в Москву из Ярославля. Компания предлагает очень заманчивый релокационный пакет, от которого практически нереально отказаться, особенно кандидатам из провинции: билеты, отель на первое время, риелтор, оплата первого месяца аренды, перевозка вещей, подъёмные. Это же твой реальный шанс переехать в столицу и устроиться на такую крутую работу! Про то, что ты, по сути, попадаешь в рабство на один год, в момент получения оффера совсем не думаешь, а надо.


    Моя релокация стоила как вся моя зарплата за 4 месяца. В такой ситуации отработать меньше года, пока Компания не спишет твой долг, ты уже не можешь. Я бы рекомендовал не брать релокационный бонус, самостоятельно арендовать номер в отеле и самостоятельно искать жильё в Москве. Либо принять правила игры и позволить Яндексу всё это сделать за вас.


    Уровень дохода


    Яндекс платит ниже рынка. В принципе, все это знают и понимают. И, когда вы будете устраиваться в Компанию, вас постараются максимально продавить по зарплате. Вам будут рассказывать о перспективах, о том, как хорошо и классно работать в Яндексе, о ДМС, о компенсации питания, о RSU и полугодовых премиях, а потом намекнут, что некоторые секции собеседования вы прошли не так уж шикарно, поэтому запрашиваемую вами сумму предоставить не могут, но могут дать немного меньше. И это «немного» будет зависеть только от вас: вы либо изначально попросите с хорошим запасом, либо попытаетесь отстоять свои пожелания…


    Многие идут в Яндекс за строчкой в резюме, поэтому они готовы подвинуться в зарплате.


    Быть как FAANG


    Яндекс – это совсем не Microsoft, Google или Amazon, но тем не менее Яндекс постоянно пытается сравнивать себя с крупными зарубежными компаниями и примерять на себе их наработки. Одно только желание загнать всех в общий монорепозиторий чего стоит. И никому нет дела, что пользы от этого монорепозитория чуть меньше, чем ноль, и что этот переход ломает устоявшуюся инфраструктуру, привносит новые ошибки, блокирует продуктовую разработку, и в конечном итоге ухудшает качество сервисов. Это чисто политическое решение сверху: у Microsoft есть монорепа – у нас тоже будет!


    Я не являюсь противником монорепозиториев как таковых, сама идея интересная и может принести определенный профит. Но как часто бывает – хорошие идеи разбиваются о скалы отвратительной реализации… и эффективных менеджеров.


    Только представьте: в один общий репозиторий мы положим код на самых разных языках (C++, Python, Go, Java) и для всего этого напишем свою новую универсальную систему сборки. Пусть Java-разработчики компилируют плюсовый код, пусть забудут про всё, что есть в Maven и Gradle, и пусть работать это будет только на Linux…


    Велосипедостроение


    Следующая проблема – обилие собственных «велосипедов». В Яндексе я впервые так явно столкнулся с проблемой «фатального недостатка»: на любое внешнее решение или технологию мы напишем свой in-house вариант. В Компании работает очень много действительно крутых разработчиков, которые могут практически всё, что угодно. Но вот стоит ли тратить их усилия, чтобы написать свою версию Кафки или пародию на Docker и Kubernetes?


    Как разработчик вы будете вынуждены постоянно разбираться в этих внутренних велосипедах, абсолютно не развиваясь в релевантных для внешнего рынка направлениях. Выйдя через несколько лет за пределы Яндекса, вы рискуете оказаться в неприятной ситуации, когда ваши умения практически ничего не стоят.


    Нигилизм


    Следующее, с чем придётся столкнуться, это отрицание и обнуление всего вашего предыдущего опыта. Эффективным менеджерам внутри не важно, чем ты занимался раньше, и что ты умеешь. Тебя обязательно засунут на проект, где у тебя меньше всего опыта, а область, где у тебя есть знания, отдадут человеку, который в ней не разбирается. Матрицы компетенций? Нет, здесь так не принято.


    Запомните эту фразу: «Здесь так не принято. Тут так не принято. В Яндексе так не принято». Вы будете слышать разные её вариации очень часто. Здесь считается нормальным посадить senior разработчика «грепать» логи с нескольких хостов, потому что ELK-стек not invented here.


    Понятное дело, что велосипедостроение есть практически везде. Проблема в том, что в Яндексе оно возведено практически в абсолют.


    Переработки


    Ещё одна из проблем – это переработки. За это никто не платит, это никак не регламентируется, но всеми подразумевается. Со стороны руководства это звучит примерно так: мы дали вам гибкий график и возможность удалённой работы, поэтому вы обязаны…


    Разработчики каждого сервиса сами отвечают за его функционирование в production’е. Для этого вводятся так называемые недельные факап-дежурства. Обычно, существенная часть доработок выкатывается во второй половине дня, и соответственно бОльшая часть инцидентов случается поздно вечером. А ночью ты их чинишь. За просто так, за бесплатно – ни денег, ни отгулов. А утром, будь добр, иди на работу. Отказаться нельзя – здесь так не принято.


    В итоге получается, что ты «вджобываешь» по 10-12 часов в день, в том числе и на выходных. За попытки как-то изменить этот процесс тебя назовут токсичным и нелояльным Компании сотрудником. Это поставит крест на твоём карьерном и зарплатном росте.


    Текучка кадров


    Такая организация рабочего процесса порождает профессиональное выгорание и текучку кадров. Ни на одном из предыдущих моих мест работы не было такой текучки, как в Яндекс.Маркете.


    Рабочих рук всегда не хватает, поэтому тобой будут затыкать все дыры: сегодня ты здесь, завтра там. Эффективные менеджеры считают, что все Java-разработчики абсолютно универсальны, смена контекста ничего не стоит, а люди просто обязаны на новом проекте перформить так же хорошо, как и на предыдущем.


    С одной стороны, смена проекта не так уж плоха: она позволяет не утонуть в болоте перекладывания json’ов из одного сервиса в другой, но реализовано это традиционно из рук вон плохо – в ультимативно-приказном порядке, прямо здесь и сейчас. Если у тебя остались нерешённые задачи (в том числе поддержка) по предыдущему проекту, угадайте, когда вы будете их делать? Правильно – вечером, ночью, на выходных.


    И ещё, если вам предложили подумать о переходе в другую команду, то вы не можете отказаться. Даже если ваш руководитель говорит об обратном. Любой отказ делает вас человеком нелояльным Компании со всеми вытекающими.


    Legacy и руководство


    Решения руководства обсуждению не подлежат. Даже не думайте критиковать и подвергать сомнению архитектуру системы, созданную пять-шесть лет назад людьми, которые теперь являются вашими руководителями. Особенно если критика конструктивна, а проблема мешает дальнейшему развитию сервиса. Не надо грести против течения. Здесь так не принято.


    Воплощение в жизнь любой стоящей идеи будет требовать от вас колоссальных усилий и, разумеется, переработок.


    Заниматься техническом долгом? Здесь так не принято.


    Качество кода


    Текучка кадров, частые смены команды и желание всё сделать побыстрее приводят к тому, что качество кода оставляет желать лучшего. Иногда код настолько паршивого качества, что вызывает лишь недоумение: как все эти классные люди написали такое? Системно этим заниматься никто не хочет: нет ни статического анализа, ни метрик, ни подсчёта code coverage. Нет, если хочешь, то, пожалуйста, сделай. Когда? Ну вы поняли…


    А ещё очень много проектов, которые собираются и запускаются только на Linux. Если у тебя Mac, то есть хоть какая-то надежда, а вот с Windows её вообще нет. И ладно бы это был плюсовый код, но что мешает на Java разрабатывать кроссплатформенные решения? Оказывается, многие просто этого не умеют. Ведь этого не спрашивают на интервью. И даже не надейтесь, что на "финале" кто-нибудь честно скажет вам, что ноутбук нужно брать только на Linux.


    Ревью и премии


    Премию по итогам ревью заплатят, но, чтобы получить хорошую оценку, придётся играть по всем выше озвученным правилам с переработками и прочим. При этом недостаточно просто хорошо работать, нужно ещё уметь красиво преподнести свои достижения.


    Я прошёл три ревью и три раза получил оценку "выше ожидаемого", но повышения грейда мне это не принесло. На вопрос почему, мне сказали, что за всё это время у меня не было значимых задач, поэтому grade-up не будет. Значимых задач, Карл!


    И здесь ты попадаешь в замкнутый круг: задачи тебе приходят сверху, и ты их не выбираешь. Даже, если задача дерьмо, ты будешь её делать. Отказ клеймит тебя человеком, нелояльным Компании. Попытка что-то доказать делает тебя токсичным, что тоже клеймо. Ну вы поняли…


    Я работал над Брингли, который закрыли. Всё, что мы сделали за несколько месяцев, помножили на ноль. Неудачу, по сути, списали на команду разработчиков и тестировщиков. Людям понизили оценки на ревью, хотя обещали этого не делать. Естественно, часть людей уволилась после этого. Но не я, я не мог, поскольку мой год ещё не закончился...


    Наём, обучение, личный рост


    В Яндексе есть проблема с наймом. Оценивается, в основном, умение решать алгоритмические задачки. Это конечно хорошо, но в большинстве случаев абсолютно бесполезно в повседневной работе. Нанимать людей под конкретные задачи или с определенным набором практических умений и навыков здесь не принято. Нужен разработчик, хорошо знающий MS SQL Server? Нанять его со стороны? Пфф, да ни за что! Лучше мы кого-нибудь из своих на этот проект засунем, даже если у него нет опыта работы с MS SQL.


    Развивать своих сотрудников Компания так же не заинтересована. Никаких индивидуальных планов развития – здесь так не принято. Можешь заниматься чем угодно, но в свободное от работы время.


    За время моей работы Компания потратила на моё обучение ровно ноль. Более того, все мои попытки поучиться и попасть на профильные конференции были заблокированы руководством. Сначала я был на испытательном сроке, во время которого Компания не оплачивает участие сотрудников в конференциях. Затем мне заявили (в июне), что бюджет на текущий (2019) год исчерпан. В 2020-м я смог выбить билет на JPoint, его оплатили, но потом из-за пандемии Яндекс аннулировал участие сотрудников в конференциях. Ничего личного, просто политика.


    Угадайте, как я узнал, что мой билет на JPoint аннулировали? Правильно, от организаторов JPoint. Яндекс же не считает нужным сообщать о подобных вещах своим сотрудникам.


    Заключение


    Не хотелось бы, чтобы эта статья выглядела как излияния обиженного сотрудника. Идя в Яндекс.Маркет, я понимал, что это не навсегда и даже не надолго. Правда по окончанию первого года работы я рассчитывал на повышение ЗП и планировал ротироваться в Яндекс.Облако, но, увы, первого не случилось, а второго уже не захотелось.


    Тем не менее, если бы сейчас я мог вернуться во времени назад, то всё равно пошёл бы работать в Яндекс.Маркет. Это хороший опыт в плане развития soft skills и заведения новых знакомств с очень крутыми разработчиками.


    Для меня работа в Яндекс.Маркете не стала работой мечты. Возможно, для вас она такой станет. Дерзайте. И да пребудет с вами Java.

    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 788

      +7
      Спасибо, итересно было почитать, сейчас уже на новом месте? Как оно там?
      Я работал над Брингли, который закрыли


      Что-то знакомое, думаю.
      Как я проработала 3 месяца в Я.Маркете и уволилась
      Но не все так радужно. Не успела я проработать и месяц, как Сбер объявил о прекращении финансирования Bringly, проект оказался убыточным


      Про Брингли мало деталей к сожалению.
        +16

        Да, уже на новой работе. Пока очень динамично — огромное количество новой информации.
        Про Брингли, если честно, не хочется говорить. Я помню свой первый день в Яндексе, 05 марта 2019, как сидел в Мулен Руж (конференц-зал) и слушал про трансграничное направление Маркета. Уже тогда было понятно, что оно не полетит. Идея строилась вокруг брендированной одежды и обуви из Турции… Ну такое… Стоимость логистики + турецкий подход к бизнесу всё убили. А конкурировать с АлиЭкспресс на товарах из Китая нереально.

          +37
          Крупные компании прощупывают ниши, это нормально. Но сваливать на разрабов проблемы маркетинга это низко, подобное можно ждать от шаражки с взбаломошным директором, но никак от крупной компании.
            –8
            но никак от крупной компании
            Самая главная и очевидная ошибка — а с чего вы взяли что это крупная компания? По меркам бизнеса — это типичный средний бизнес со всеми вытекающими проблемами среднего бизнеса по определению.
            И второе — «кто-то там» сказал, что ожидания болельщиков — это проблемы болельщиков. Это я про то, что если кто-то там шибко обольщался, ну так это проблемы того кто обольщался. Не более того.
              +54
              Есть конкретные критерии крупного бизнеса — доход более 2 млрд руб, количество работников — более 251 человек. Яндекс под эти критерии подходит. Так что это не я взял, это общие критерии для РФ, могли бы и погуглить, а не задавать глупых вопросов.

              И про болельщиков я не понял — что вы этим хотели сказать? Если для вас норма сваливать на разрабов менеджерские просчеты, то идите в… Яндекс, там такое цветет и пахнет.

              В нормальных компаниях за завершенный и работающий проект, даже если он не пошел по каким-то причинам, исполнителей премируют. Не должен исполнитель отвечать за промашки руководства, он наемный работник, а не бизнес партнер.

                –14
                +1
                  +4
                  А где обман-то?
                  8854 > 251
                  754млн USD ~ 51млрд. RUB > 2млрд. RUB
                    +2
                    Извините, не так прочитал.
                    0
                    8854 больше, чем 251.
                    745 млн долларов больше, чем 2 млрд рублей.
                    Разве не так?
                      +6

                      А что было в оригинальном коммаентарии, если кто помнит? Сейчас там +1.

                        +2
                        Комментатор обвинил комментатора во вранье, но ошибся сам :)
                          0
                          Привёл доказательства правоты автора.
                          А комментарий следовало писать под предыдущим постом.
                          +1
                          Комментатор неправильно прочитал коммент на который отвечал, решил что в нем озвучены не критерии большой фирмы а количество людей и доход Яндекса. И весьма прямолинейно обвинил автора во лжи.
                      –8
                      Хм… Сколько злобы. :))) А зачем?

                      Итак, что вам даёт число? Скорее всего чуть менее чем ничего. Число никак не раскрывает экономическую модель бизнеса. Для маразматичного налоговика число может быть что-то там да и даёт, но вменяемым — вряд ли…

                      Бизнес как водится трёх видов бывает. Мелкий, средний и крупный. Критерии сего определяются вовсе не какими то там числами, а экономическими моделями. Про мелкий смысла нет говорить, с ним всё понятно. Средний — это когда дело доросло до вменяемого размножения самого себя. Крупный — это средний + производство базовых «орудий труда» для дела. Само собой это всё слишком грубые критерии, если нужны более чёткие — учебник экономики откройте, а не налоговый кодекс, или что там вы открыли от рашенских маразматиков — тут уж я понятия не имею…
                      И про болельщиков я не понял — что вы этим хотели сказать?
                      Ниже строка.
                      Это я про то, что если кто-то там шибко обольщался, ну так это проблемы того кто обольщался. Не более того.

                      И да, яндыкс — это средний бизнес, торгующий гавённой третьесортной рикламкой вразнос. Не более.
                      Причём заметьте, яндыкс является средним бизнесом даже с небольшой натяжкой вообще-то…
                        +3
                        Крупный — это средний + производство базовых «орудий труда» для дела.
                        получается, что крупный бизнес — это средний делающий велосипеды для себя :)
                        И Яндекс по ваше определение точно подходит :)
                          –9
                          Не знаю зачем яндыксу «велосипеды». Это у яндыкса спрашивать нужно.

                          «Орудия труда» в данном случае — это операционки, браузеры, всякие ноды, серваки и всё то, что базово помогает яндыксу далее создавать «продукты», продающие рекламу. Это и есть «орудия труда». Первоначальные экономические зависимости.

                          Ой простите. Это не про яндыкс. Ахаха! :)

                          А у яндыкса похоже что да, только калешные монструозные виласипеды… Тут вы возможно правы.

                          пс: Сбоку Хабра подкинула «совершенно случайно»: «Google делает свой процессор, а AMD готовится уничтожить Qualcomm». Конечно же это просто совпадение, не более.
                            0
                            Хахаха, вот ты не в курсе что гугл делает ARM процессор для консьюмерского рынка. Делать на нем серьезную работу никто не собирается, он для телефончиков. По твоим некомпетентным маразматическим критериям даже гугл — средний бизнес, так что ты так обсратушки, что просто смешно.
                            Сам себе что-то выдумал, сам доказал обратное. Может тебе хоть немного изучить тему, мальчик, прежде чем лезть в разговоры взрослых людей?
                          +2
                          В путаете причину и следствие. То что вы назвали — это следствие укрупнения бизнеса. И яндекс по вашему же определению — крупный.

                          И если уж говорите «посмотри в учебниках» — то давайте ссылки, где это написано, чтобы я ознакомился с полным текстом, а не вашей интерпретацией, которая в корне не корректна.

                          И если вас не устраивают рашенские маразматики, то в ЕС критерии крупного бизнеса — более 250 человек, а также более 50 млн евро или общим балансом 43 млн евро.

                          Может если кругом маразматики, то маразматик — это вы? Особенно мне понравилось «торгующий гавённой третьесортной рикламкой вразнос». Смешно. Сам этот маразм выдумал?
                    0
                    Joom?
                    –10
                    Прошу не распространяйте этот фейк, тамошнего автора разоблачили: habr.com/ru/post/470337/#comment_20721735

                    К тому же она дискредитировала Хабр в глазах IT-сообщества, показав как легко заручится поддержкой, если ты женщина, вскружив мужской части сообщества голову, т.к ранее был аналогичный пост от лица мужчины, где большинство комментаторов его загнобила, жестко загнав в минуса, и даже вынудив его покинуть хабр, а в случае с Юлией несмотря на одинаковые повестки, попросту носили на руках.
                      +13

                      Эм… но вот прямо здесь и сейчас публикация от лица мужчины (вроде). Пересечение по отдельным моментам этой и той статьи есть. И эта статья в плюсе. Может дело всё-таки было не в поле автора, а в содержании статьи и подаче материала? Одни и те же факты можно описать и так, что уйдёшь в глубокий минус, и так, что на руках будут носить.

                        –14
                        Честно говоря я не оригинальную пост о которой упоминаю, об этом писал человек в комментариях, но читая многие статьи на хабре еще давно заметил, что отношение сильно зависит от пола, если это мужчина, то «сам виноват, думать надо было», если девушка, то «не переживайте вы так» и всё в таком духе, но суть не в этом.

                        И дело как раз таки в поле автора, иначе как объяснить то, что у 90% хаброчан просто отключались критическое мышление, и даже когда им открыто демонстрируют факты, они принимаются спорить или оправдывать автора, скажите мне как, как это возможно? Разве это не отличительная черта сильного пола, щелкать в голове рубильником, при виде слабого?

                        Вполне возможно что того автора загнобили за дело, но это лишь очередная наглядная демонстрация того, что если автор мужчина, то люди не верят на слово, не бояться быть прямолинейными и высказывать своё мнение, а посмотрите на пост Юлии, 90% попросту поверили на слово, принялись утешать, шутить, пытаться разрядить обстановку, и даже спорить с разоблачителями, какой контраст однако.

                        Впрочем не удивительно, ведь женщины в IT редкость, что только повышает их ценность в наших глазах.
                          +13

                          Два человека написали статью на одну и ту же тему. Обе в плюсе. Но вы говорит, что


                          • у Юли статья в плюсе, потому что она женщина
                          • у Ивана статья в плюс, потому что он дело правильные вещи

                          Я правильно понимаю вашу мысль? о_О

                            –18
                            Те, кому нравилось работать в Яндекс.Маркете, не пишут такие статьи=)
                            Кто плюсует мне тоже интересно. Это достаточно забавно и интересно читать, но всё же ценность таких статей околонулевая (ИМХО) по сравнению с техническими статьями.
                            Ну вот прочитает человек такую статью, решит что Яндекс говно и не пойдет туда. Кому от этого лучше? Человеку, который не получит полезный опыт создания scalable систем? Яндексу, который не получит (возможно) ценного сотрудника?
                              +14
                              Очевидно, человеку, который не пойдёт и не разочаруется в компании сам (если он прочтёт статью и поймёт, что разочаровался бы).
                              А полезный опыт создания масштабируемых систем можно далеко не только в Яндексе получить.
                                +7

                                Прежде всего самому Яндексу. Чем больше нашумит статья, тем больше вероятность, что высшее руководство с ней ознакомится и предпримет какие-либо меры. Без такой обратной связи компания собственно и докатилась до текущего состояния. В Яндексе, собственно, политика такая вместо того, чтобы строить внутренние процессы так, чтобы не было стыдно, если вдруг что-то станет достоянием общественности, — там бьют по башке всех, кто хотя бы минимально проявит свою нелояльность.

                                  +1
                                  Прежде всего самому Яндексу. Чем больше нашумит статья, тем больше вероятность, что высшее руководство с ней ознакомится и предпримет какие-либо меры.

                                  Я работал в каком-то другом маркете и ничего подобного описанному в статье у нас не было. Либо всё за 2 года ТАК испортилось, либо автор слегка (совсем чуть-чуть) преувеличивает проблемы.
                                  Представим теоретическую ситуацию что в статье — ложь. Что должно делать руководство в этом случае? Ну проведут они расследование, выяснят, что переработок нет или почти нет, статический анализ есть и на венде люди прекрасно работают, а человек просто обиделся на что-то, вот и пишет всякое. А потом другой человек прочитал это и не пошел работать в Яндекс, основываясь на недостоверных/неполных данных. Кто в этой теоретической ситуации выиграл?

                                  В Яндексе, собственно, политика такая вместо того, чтобы строить внутренние процессы так, чтобы не было стыдно, если вдруг что-то станет достоянием общественности, — там бьют по башке всех, кто хотя бы минимально проявит свою нелояльность.

                                  Вы это говорите на основании собственного опыта?
                                    0

                                    Ну, представлять-то можно много чего. Например, что всё именно так как автор и написал, или даже всё на самом деле ещё хуже, но руководство не в курсе.


                                    Агась.

                                      +2
                                      Да даже бывшие/нынешние сотрудники Маркета (вроде меня) не в курсе происходящих ужасов, что уж о там о руководстве говорить=)
                                      Мой изначальный поинт в том что не надо принимать на веру всё что пишут в интернетах и автор может быть (скажем мягко) не совсем объективен.
                                      Да, во всякую дичь легче поверить — я когда читал всё это поймал себя на мысли «ну нихрена себе там у джавистов», но, поразмыслив, всё же решил, что слова автора надо делить примерно на 10. Например его поинт про то что на маке/венде не собирается разбивается о то, что это и не нужно делать ибо неудобно — яндексовая система сборки позволяет собирать удаленно на (линуксовых) серверах. Зачем собирать 2 часа утилиту если можно собрать ее за 10 минут на сервере? Опять же, когда я устраивался я всё это выяснил заранее и не стал брать Мак (вероятно, зря).
                                      Если бы я до сих пор работал в Маркете и был в курсе что там в команде джавистов я бы мог подтвердить или опровергнуть описанное в статье. Из того, что я видел и где я работал — ничего подобного и близко не было.
                                        +8

                                        Ну а меня в своё время уволили за неосторожное малозначительное сообщение в личном блоге, никак не афилированном ни со мной, ни с яндексом, который почти никто не читал. Ещё и полагающуюся при этом компенсацию платить не хотели. Собственно, в корпоративной вики так прямо и было написано, мол писать в своём блоге вы, конечно, можете что угодно, но имейте ввиду, что коллеги могут не захотеть после этого с вами работать. Мне вот и повезло, что со мной не захотел работать руководитель проекта.)


                                        Нытьё про работоспособность java-приложения под виндой я тоже не разделяю, но у всех свои тараканы. И в любом тексте можно найти какой-нибудь изъян, что не делает этот текст ложным.

                                          +2
                                          Ну а меня в своё время уволили

                                          Ого, ничего себе. А можно подробности (в личку)?

                                          И в любом тексте можно найти какой-нибудь изъян, что не делает этот текст ложным.

                                          Ну так там не один такой изъян — про монорепу фигня написана, про качество кода, про велосипеды, про легаси. То есть оно конечно в какой-то мере есть (покажите мне проект без легаси), но не это ужас-ужас достойный целой статьи.
                                          С чем я могу согласиться — это переработки, но это как-то о-малое от всего описанного.
                                            +1

                                            Я мало уже помню подробностей.


                                            Не сказал бы что фигня. Какой смысл держать в монорепе не связанные друг с другом проекты? Тем более, что правильно приготовленная мультирепа ничем не хуже.

                                              0
                                              Смысл в монорепе в том что у вас есть легкий доступ к тем самым велосипедам. И да, «не связанные» проекты в том числе хотят иметь этот доступ. Нужна библиотечка из Утилей — подключили одной строкой в ya.make. Захотела ваша тулза из 10 строк ходить в YT — фигня вопрос, ну подумаешь вместо 10 секунд компилируется теперь 40 минут. Зато экономится время разработчика — не надо пилить свой локальный велосипед когда есть алгортим/функция/библиотека/велосипед в Аркадии. Например, поиск Маркета юзает плюс-минус тот же код, что и основной поиск.
                                              Не, я не спорю, что при должном тулинге можно сделать это и на мультирепах, но проблема в том что и в случае монорепы и в случае мультирепы этот тулинг нужен (ни то ни другое не является серебрянной пулей и не работает из коробки) — в силу тех или иных причин Яндекс выбрал монорепу и связанный с ней тулинг. Утверждать, что монорепа — говно, «забыв» о необходимости (другого) тулинга для мультирепы — это писать фигню, потому что складывается впечатление что в Яндексе дурачки, а вот мультирепа все проблемы решит из коробки.
                                                +1

                                                что монорепа, что мультирепа — оба подхода требует обмазывания соответствующими тулингами. Но в случае мультирепы ты еще можешь взять условный гитлаб, то. в случае монорепы даже Майкрософту пришлось написать адаптированную фс для гита, чтобы эффективно работать с большой кодовой базой

                                                  0
                                                  Да, гитхаб это клево и удобно, а как быть с переменованием функций, например? В Аркадии я могу взять и заменить Stroka на TString одним коммитом.
                                                  А вот взять товарищей из Qt, у них мультирепа. Вот я хочу переименовать функцию из QtCore которая используется в другом сабмодуле. Это надо добавить функцию-обертку, закоммитить, пойти в другой модуль, заюзать враппер там, закоммитить, пойти в QtCore и наконец переименовать функцию, избавившись от обертки, закоммитить. Не слишком ли много действий для такой простой задачи?
                                                    +2
                                                    В Аркадии я могу взять и заменить Stroka на TString одним коммитом.

                                                    По отдельному коммиту в каждую фичеветку каждого проекта тогда уж.


                                                    А чтобы такой ерундой не заниматься такие вещи лучше оформлять в виде какого-нибудь codemod, который запускается автоматом после слияния.


                                                    А вот взять товарищей из Qt, у них мультирепа. Вот я хочу переименовать функцию из QtCore которая используется в другом сабмодуле.

                                                    Похоже они перестарались и зачем-то разрезали один проект на несколько реп, что ничего кроме проблем не даёт. На репы имеет смысл нарезать по зоне ответственности.

                                                  +1

                                                  То есть по ссылке вы не ходили? Там как раз описывается система которая автоматически выкачивает зависимости по мере их использования. Как из npm так и из отдельных репозиториев. Был бы я Яндексом, то отмасштабировал бы её и на яву и цпп. Но я не яндекс.


                                                  Вы мне можете не рассказывать проблематику, я с ней прекрасно знаком. Вообще, забавная ситуация. Я уже давно не работаю в компаниях масштабов яндекса, но с тех пор решил в своих инструментах множество специфичных для этих масштабов проблем. А яндекс не то что решить их не смог толком, но даже не интересуется моими наработками.


                                                  Тулинг там довольно тривиальный: обнаружил зависимость от директории — выкачал в неё репозиторий.

                                                    +2
                                                    Я пролистал ссылку, понял что ничего не понимаю в Джаваскрипте и закрыл — я сходу не увидел высокоуровнего описания, а вникать в портянки кода на ЖС у меня нет желания, извините, веб разработка — не моё.
                                                    Нет, я прекрасно знаю, что все эти проблемы решаемы в мультирепе, скажем, в 2 Гисе был свой набор скриптов для этого. Можно и деб-пакеты собирать из различных репозиториев и рулить зависимостями на этом уровне, тоже подход. По всякому можно, я и не утверждаю что монорепа лучше чем мультирепа, я утверждаю что безапелляционно заявлять что «Х — говно» это профанационный уровень, которым проникнута вся статья.

                                                    Тулинг там довольно тривиальный

                                                    Именно так и работает селективный чекаут в ya make=)
                                                      +3

                                                      Но это реально говно. Такой подход не масштабируется. Полирепу же легко масштабировать.

                                                        +1
                                                        Это очень спорное утверждение. Сразу хочу сказать, что я не фанат монорепы.

                                                        Я работал с полирепой Почты — то ещё развлечение, вся фигня заключалась в том, что твою библиотеку юзали разные проекты, но каждый — какую-то версию, на которой они зафиксировались. Обновить у всех свою библиотеку, когда ты делаешь там фичу или баг какой чинишь, было ооочень сложно.

                                                        Я довольно долго использовал парадигму дебиановских пакетов и бинарную зависимость. Что я могу сказать: бинарная зависимость в C++ — это боль. Отдельно доставляют циклические зависимости, если у программ есть плагины. Ещё раз отдельно, но уже по-другому, доставляют переезды на новые версии ОС, когда тебе надо пересобрать ВСЁ, даже какие-то старые коммон-библиотеки, которые уже года 3 как заморожены.

                                                        Я даже дружил библиотеки, собранные из монорепы, с бинарными сборками в дебиановские пакеты, и отлов багов с клэшингом символов — это прям особое «удовольствие».

                                                        Стоит отметить, что везде это был C/C++ код, со всеми его проблемами динамической или статической линковки. Но общие моменты, что надо уметь делать минорные релизы, которые не ломают API+ABI, думаю, будут применимы ко всем языкам. Это тяжело, и это форсит накапливать подобные несовместимые изменения в большие пачки и делать большие мажорные релизы, которые требуют много работы для внедрения, переписывания кода у использующих данный код проектов и т.д. А пока все медленно переползают — надо поддерживать 2, а то и 3 мажорных релиза. И да, сложность поиска кода действительно есть, найти, из чего именно был собран какой либо бинарник/пакет далеко не так тривиально, как может показаться. Есть ещё «вирусные» изменения, типа включения поддержки нового стандарта C++ — это тянет за собой включение сборки с этим же стандартом и у всех зависимых компонентов. На сколько я понимаю, у Java есть примерно такая же фигня с целевой версией JVM, и примерно такая же проблема у JS кода, подобным «вирусным» изменением может быть использование более новой версии питона при разработке какой либо библиотеки.

                                                        В противоположность этому монорепа требует вносить изменения плавно и итеративно, можно даже вносить изменения, ломающие API, но своим же коммитов исправлять все использования из чужого кода, главное — сохранять совместимость на уровне сетевого протокола и формата данных. Да, это требует наличия тестов у проектов. Да, это несколько усложняет разработку в бранчах (поэтому обычно монорепа соседствует с trunk-based разработкой), но позволяет делать такие изменения у популярных, с точки зрения количества использующих их проектов, библиотек. Важно отметить, что монорепа — это не столько большой SVN/Mercurial/git/whatever, сколько система сборки, система контроля зависимостей, тестирование, система CI/CD и т.д.
                                                          +3
                                                          вся фигня заключалась в том, что твою библиотеку юзали разные проекты, но каждый — какую-то версию

                                                          То есть проблема в фиксации версий, а не полирепе.


                                                          Я довольно долго использовал парадигму дебиановских пакетов и бинарную зависимость.

                                                          А тут соответственно проблема в попытке полагаться на бинарную совместимость, а не полирепе.


                                                          А пока все медленно переползают — надо поддерживать 2, а то и 3 мажорных релиза.

                                                          Не надо поддерживать устаревший код. Тогда переползать будут гораздо быстрее.

                                                            +1
                                                            То есть проблема в фиксации версий, а не полирепе.

                                                            А какие предложения есть? Как вообще искать все проекты, которые используют твою библиотеку, особенно если разработка идёт в фиче-бранчах?

                                                            А тут соответственно проблема в попытке полагаться на бинарную совместимость, а не полирепе.

                                                            А на какую зависимость надо полагаться? Если по исходникам, то как фиксировать?

                                                            Не надо поддерживать устаревший код. Тогда переползать будут гораздо быстрее.

                                                            Как синхронизировать разработку, если твою библиотеку использует 50 проектов?

                                                            Вы абстрактно хорошие вещи говорите, но как их воплотить в реальную жизнь? Можете рассказать, как вы это видите для компилируемых языков?
                                                              0
                                                              Можете рассказать, как вы это видите для компилируемых языков?

                                                              Какая разница — компилируемый ли язык или интерпретируемый? Та или иная форма "dll hell" и необходимости менеджить зависимости никуда не девается. Самое простое, конечно, статическая линковка и затаскивать внешние модули целиком (и собирать вместе с ними). Сильно сложнее, когда зависимости через артефакты. Но ничего нового Вы не сказали — так или иначе эта проблема характерна для любой разработки. Как со стороны потребителей готовых блоков (библиотек), так и со стороны разработчиков (которым приходится поддерживать несколько версий в параллель и давать определенные гарантии на интерфейс библиотеки).
                                                              Теоретически можно построить фашизм и заставить всех использовать только последние версии в рамках отдельно взятой организации, но это просто космическое количество человеко-часов, чтобы поддерживать весь код в актуальном состоянии (а то! Думали, что айти это дешево и просто на кнопочки клацать!)


                                                              Кстати, я плачу горючими слезами, но в python до сих пор есть "детские" проблемы с менеджментом пакетов.

                                                                +2
                                                                Как вообще искать все проекты, которые используют твою библиотеку, особенно если разработка идёт в фиче-бранчах?

                                                                Не надо вообще таким заниматься. Заботиться об обновлениях — задача потребителя вашего кода. Вы можете ему помочь, если не будете ломать апи, а слом апи сопровождать codemod-ом, ну или хотя бы внятным сообщением об ошибке, из которого понятно как починить.


                                                                А на какую зависимость надо полагаться? Если по исходникам, то как фиксировать?

                                                                Не фиксировать. Вы бы всё же прочитали ту статью. Хотя бы раздел про версионирование. Там JS специфики не много, а проблемы рассматриваются довольно типичные.

                                                                  0
                                                                  Собственно, в комментарии habr.com/ru/post/456288/#comment_20290512 поднимались проблемы, на которые не было получено ответа.

                                                                  По сути вы предлагаете trunk-based разработку, но, в отличие от монорепы, автор библиотеки не обязан проверять, что тот самый виртуальный общий транк (то есть все текущие последние ревизии/версии всего, что есть в репозитории) собирается и проходит тесты.

                                                                  Простите, но ваши фразы типа
                                                                  Заботиться об обновлениях — задача потребителя вашего кода.
                                                                  мне говорят о том, что вы коммон библиотеки или клиенты для своего сервиса, которыми пользуются потребители, не делали. Им, потребителям, надо, чтобы работало, а не тестировать ваши изменения по 10 раз на дню.

                                                                  А фраза
                                                                  Вы можете ему помочь, если не будете ломать апи, а слом апи сопровождать codemod-ом,
                                                                  говорит о том, что вы совершенно не поняли мои слова про ABI.

                                                                  Если бы мне предложили работать с какой либо библиотекой в концепции «автор может делать много изменений, поддерживает только транк/мастер, но на ваш (то есть мой) сервис ему, в целом, наплевать» — то я бы поостерёгся ею пользоваться и пошёл искать альтернативы.

                                                                  Почему же в реальной жизни все JS-еры фиксируют версии? Почему не собирают всё на самой последней версии? Почему существуют LTS версии библиотек и даже операционных систем? Ваша концепция (vintage — это же вы?) не выглядит какой-то уникальной, почему никто не живёт так, если она столь хороша?
                                                                    +2
                                                                    По сути вы предлагаете trunk-based разработку

                                                                    Вовсе нет. В фичеветках, как обычно.


                                                                    автор библиотеки не обязан проверять, что тот самый виртуальный общий транк (то есть все текущие последние ревизии/версии всего, что есть в репозитории) собирается и проходит тесты.

                                                                    Конечно, для этого существует CI


                                                                    Им, потребителям, надо, чтобы работало, а не тестировать ваши изменения по 10 раз на дню.

                                                                    Вы зачем 10 раз в день ломаете мастер? Не надо так. Настройте CI чтобы не давал вам пушить в мастер непротестированный код.


                                                                    на ваш (то есть мой) сервис ему, в целом, наплевать

                                                                    Не наплевать. Просто ваш сервис — это ваш сервис. А его библиотека — это его библиотека. Бегать по 100500 сервисам и делать в них изменения видя код в первый раз в жизни — это мало того, что контр продуктивно, так ещё и опасно. К тому же открывать автору любой библиотеки доступ к вообще всем репозиториям — ну такое себе.


                                                                    Ваша концепция не выглядит какой-то уникальной, почему никто не живёт так, если она столь хороша?

                                                                    Мы тут не в "пусть говорят", чтобы использовать апелляцию к толпе в качестве аргумента.

                                                                      0
                                                                      Конечно, для этого существует CI

                                                                      Ваш, или для вот тех проектов? Если у вас полирепа, то откуда вы вообще про их CI узнаете? Они там, с другой стороны компании, и вообще у них Teamcity, а не Jenkins.

                                                                      Настройте CI чтобы не давал вам пушить в мастер непротестированный код.

                                                                      Непротестированный моими тестами, или тестами пользователей моей библиотеки?

                                                                      Мы тут не в «пусть говорят», чтобы использовать апелляцию к толпе в качестве аргумента.

                                                                      Это называется «проверка жизнью». Удачные концепции распространяются между компаниями и коллективами разработчиков, неудачные — забываются. И почему вы пропустили ту часть абзаца, где было про LTS и про жизнь на самой новой версии из NPM вот прям сейчас?
                                                                        +2
                                                                        Конечно, для этого существует CI

                                                                        Если CI единое для всех проектов, то это уже, по сути, монорепа и есть. То, что у каждого проекта свой репозиторий, а не папочка в монорепе — сути не меняет.

                                                                          0
                                                                          Если CI единое для всех проектов, то это уже, по сути, монорепа и есть.

                                                                          очень спорный аргумент.


                                                                          То, что у каждого проекта свой репозиторий, а не папочка в монорепе — сути не меняет.

                                                                          в монорепе Вы в принципе не можете версионировать отдельные "папочки" — фича-ветки это несерьезно. Монорепа хороша, когда у Вас есть несколько взаимосвязанных продуктов, которые бегут по последней версии (какой-нибудь SaaS). Для коробочной разработки — монорепа может быть отдельной болью.
                                                                          В случае большого количества независимых реп — у каждой из них версионирование свое. Это может быть болью, когда нужно собрать продукт из них в кучу, но действительно ничего не мешает сделать отдельную мета-репу и в ней прописать все зависимости (версии)

                                                                            0
                                                                            в монорепе Вы в принципе не можете версионировать отдельные "папочки"

                                                                            А как это раздельное версионирование работает с единым CI?

                                                                      0
                                                                      Не надо вообще таким заниматься. Заботиться об обновлениях — задача потребителя вашего кода.
                                                                      и начинаются проблемы с версионированием, воспроизводимостью билдов/окружения и прочим. Причем энтропия версий увеличивается экспоненциально росту числа компонент.

                                                                      Плюс у монорепы есть пара «вкусных» бонусов. Например, вы можете поправить библиотеку вместе с клиентским кодом.
                                                                        +2
                                                                        Плюс у монорепы есть пара «вкусных» бонусов. Например, вы можете поправить библиотеку вместе с клиентским кодом.

                                                                        А вне монорепы, конечно, я не могу это сделать? Или все-таки могу, но Вы имеете в виду, что не за одну итерацию? Так одна итерация — это такая же фикция, потому что пока я там в trunk based монорепы буду все места править и делать тесты зелеными… ну, вы поняли

                                                                          +1
                                                                          Так одна итерация — это такая же фикция, потому что пока я там в trunk based монорепы буду все места править и делать тесты зелеными…
                                                                          для этого есть прекоммитные проверки — вы пытаетесь закоммитить, тесты фейлятся, вы меняете код, тесты зеленеют, коммитите… В итоге всё изменение (и либы, и клиентов) приходит в одной ревизии и нет промежуточных поломанных
                                                                            +2

                                                                            Это не "прекоммитные" проверки, которые должны на машине разраба отрабатывать быстро (иначе зачем они ещё нужны). А предмержевые (не могу придумать более удачного слова) проверки — на фичеветке поверх мастера. И тогда, да, они могут быть "долгими". Что более важно — может быть конвенция, что все коммиты из фичеветки при мерже в мастер должны быть схлопнуты (squash) и снабжены цельным, адекватным описанием.

                                                                              –1
                                                                              Это не «прекоммитные» проверки, которые должны на машине разраба отрабатывать быстро (иначе зачем они ещё нужны)
                                                                              никто не отменяет возможность запускать тесты на машинке разработчика*, но когда у вас помимо тестов библиотеки есть тесты её зависимостей и зависимостей зависимостей, и часть из этих тестов выполняются 10+ минут… А еще учтите баснословное время сборки всего этого зоопарка, и даже если мы не верим клиентским юнит тестам, мы должны как минимум не ломать им сборку. Поэтому реально перед тем как пытаться коммитить вы скорее всего захотите вручную запустить лишь пару самых релевантных тестов, но даже они могут тянуть столько зависимостей, что их сборка даже на мощном пк будет занимать десятки минут. Итого внимание вопрос: а зачем вообще локально что-то делать если разрабатывать на сервере продуктивнее?

                                                                              * предполагая что они вообще могут на этой машинке запуститься и отработать.
                                                                                0

                                                                                а где я говорю, что на машине разработчика тесты вообще должны гоняться? Простые проверки != юнит-тест != полный сет тестов. Ну, может на машинке разработчика максимум там линтер прогоняется. Или что там не очень дорого гонять.


                                                                                Итого внимание вопрос: а зачем вообще локально что-то делать если разрабатывать на сервере продуктивнее?

                                                                                Ну, и почему тогда Вы именно про предкоммитные проверки говорите? Прекоммит означает, что если что-то не так, то сразу все фейлится и в истории (гита, например) ничего не остается. Например, на прекомит правильно вешать проверку на наличие паролей в репо.
                                                                                А в остальном — разработчик — какая разница — пускай коммитит мусор в удаленное репо (главное, что не в мастер) — мы все равно перед мержем заставим его убрать его :-/


                                                                                Окей — у нас разный подход именно из-за того, что в нормальных компаниях нету Аркадии (и не будет).

                                                                                  0
                                                                                  Прекоммит означает, что если что-то не так, то сразу все фейлится и в истории (гита, например) ничего не остается.
                                                                                  но ведь… именно так в аркадии и происходит. И можно делать атомарные изменения одновременно либ и их зависимостей, что в мультирепе невозможно by design. В итоге я вашу критику монорепы тем более не понимаю.
                                                                  0

                                                                  Извините, ни один из Ваших аргументов за монорепу… Не серьезен.


                                                                  Полностью согласен с nin-jin ниже.


                                                                  большой SVN/Mercurial/git/whatever, сколько система сборки, система контроля зависимостей, тестирование, система CI/CD и т.д.

                                                                  Где противоречие? Повторюсь, что для любого проекта, будь он хоть в "полирепе", все указанные сущности будут нужны

                                              0

                                              Учитывая иногородний ограниченный контингент, взявший в плотное кольцо компанию, рассчитывать на самостоятельность средненизовых подразделений не приходиться. Им бы день простоять, да ночь продержаться. И так до пенсии или до волшебного пендаля. Главное не отклоняться от генеральной линии по горизонтали. Пример с тем как вас мурыжили с $mol показателен. Какие велосипедисты такие и велосипеды. Это как в известном анекдоте.


                                              nin-jin
                                              сегодня в 18:50
                                              Не то чтобы мурыжили. Просто обмен опытом никому оказался на самом деле не нужен. А на публику-то надо показывать хорошее лицо.

                                              Я считаю, что такие уникальные разработки как $mol надо поддерживать всесторонне. Тогда да можно говорить об опережающих тренды разработках. Пока Яндекс похвастать может тем что паркует react. Это может и хорошее лицо, но чужое

                                                0

                                                Не то чтобы мурыжили. Просто обмен опытом никому оказался на самом деле не нужен. А на публику-то надо показывать хорошее лицо.

                                            0
                                            Не просто потому что женщина, но потому что при этом еще и жертва.
                                            +2

                                            Забавно, если бы не этот комментарий, мне бы и в голову не пришло, что автор — девушка. Вам только кажется, что все так же как и вы смотрят на автора и его пол) Если тексте явно не указывается пол автора, я даже знать не буду, мужчина или женщина это писала. Да и не хочу — мне на это плевать, как и многим)

                                              0
                                              Сразу видно насколько внимательно и качественно вы потребляете информацию, если даже не замечаете того от чьего лица идёт повествование.
                                                +3

                                                "Обращаете внимание на пол автора? Да вы сексист!"
                                                "Не обращаете внимание пол автора? Вы ужасно невнимательны!"


                                                Нда. Без шансов :))

                                                  0
                                                  Шутки шутками, а представьте как он книги читает, не различая моментов когда повествование переходит от нейтрального, стёртого, нулевого к самому персонажу, ну а его пол наверняка определяет по имени, что приводит нас к мысли о том, а что делать если это Саша?

                                                  Ну и самое главное как можно прочуствовать тонкие моменты в повествовании связанные именно с полом? Будет странно видеть в тексте поста рассказ о том как с автором заигрывал начальник, а вы не знали что это девушка…
                                                    0

                                                    Ну если совсем серьёзно, то зависит от тематики текста. В техническом посте даже если автор использует гендерные окончания в отношении себя — они роли не играют, и могут легко выкинуться из памяти как несущественная информация. В повествовании, завязанном в первую очередь на взаимодействие конкретных персонажей — может быть крайне важно.


                                                    В этом конкретном тексте после начал данного треда мне буквально пришлось полезть в пост, чтобы уточнить пол автора. Потому что вне зависимости от пола автора монорепозиторий или Java чем-то принципиально иным не станут :)

                                                  +1
                                                  Первое же предложение в тексте:
                                                  Я уволился из Яндекс.Маркета, отработав там почти 15 месяцев

                                                  Не «я уволилась», а «я уволился». С чего мне вообще должна была прийти в голову мысль, что автор — девушка? Вторым словом в статье автор обозначает себя мужчиной, информация закрепляется, дальше уже просто смотрю на детали статьи
                                            +9
                                            Прошу не распространяйте этот фейк, тамошнего автора разоблачили:

                                            К тому же она дискредитировала Хабр в глазах IT-сообщества

                                            Почему я должен думать, что того автора 'разоблачили' и она 'плохая'?
                                            Вы так публично заявлете об этом, но ни приложив ни единого доказательства.
                                            Я вам поставил минус заслужили.

                                            Я сейчас открыл того автора sashavoloh и у нее есть статьи и высокая карма и лайков за подобную статью (про маркет) не меньше чем в этой, мне кажется, что вы что-то нездоровое 'просите'
                                              –6
                                              Почему я должен думать, что того автора 'разоблачили' и она 'плохая'?

                                              А вы и не сможете, у вас отключился мозг.
                                              Вы так публично заявлете об этом, но ни приложив ни единого доказательства.

                                              Отличная иллюстрация того, как происходит отключение мужского мозга, когда он видит что «бедную» женщину «угнетают».

                                              Так явно и нагло игнорировать доказательства по ссылке на комментарий с 76 плюсами, где под ним люди накидали еще доказательств, ссылоки на её посты твиттер, архиватч, инфу с linkedin и главное на её настоящее отношение к работе и её токсичность к мужчинам, казалось бы бери, не хочу, изучай, докапывайся до правды…

                                              Ну что Хабровчане. по прежнему будете говорить, что я безоснователен? Что все оценивали тамошнюю жертву с критическим мышлением? Что мужской мозг не отключается при виде бедняжки которую нужно пожалеть и вступиться за неё?
                                                +4

                                                Да да. Вам бы тут сообществу про токсичность втирать, обвинив изначально в отключении мозга. Мира и процветания.

                                                  +2
                                                  Человек выше на полном серьёзе считает что я не предоставил ни одного доказательства, в упор не видит ссылку, что это если не отключение мозга?
                                                  Получается вы обвиняете его в том что он сделал это умышлено? Как и люди поддержавшие его плюсом?

                                                  Не знаю как вы, а я считаю иначе, это нормальное поведение когда мужики бросаются сломя голову вступаться за слабый пол, даже не пытаясь вникнуть в ситуацию, человек может и не хотел клеветать на меня, но сами понимаете как это бывает.
                                                    +1
                                                    Вопрос не в доказательствах, какой то там девушке и её разоблачении. Вопрос в том, как это все было преподнесено.
                                                    Да и опять же — там юля, тут ваня. единственная связь, на которую изначально в комментариях — просто напомнило ту публикацию. и все. никто не защищал и не оправдывал. но пригорело в итоге у вас. а у хабражителей блекаут мыслительных процессов (с ваших слов). и вы удивляетесь негативной реакции сообщества?
                                                      +1
                                                      Вопрос в доказательствах, читайте внимательно:
                                                      ne555
                                                      Вы так публично заявлете об этом, но ни приложив ни единого доказательства.

                                                      Как это нужно было преподнести? Написал коротко, сжато, фейк, вот ссылка на доказательства.
                                                      Ниже указало почему важно не распространять этот пост. Вы вообще кстати в курсе, что тогда не хило так просела репутация хабра, на других ресурсов люди откровенно смеялись с того, как можно откровенно надуть здешнее сообщество, и остаться безнаказанной, показав всю пассивность этого самого сообщества.

                                                      На хабре есть много хороший статьей с разборами нынешней системы рейтинга, кармы, продвижения постов и общих с этим проблем, но одно дело когда это простые истории из жизни, другое дело когда пойдут вбросы и откровенная дезинформация, такие посты будет набирать огромное количество плюсов и никто этому не воспрепятствует, да и зачем? Положительный опыт уже есть, администрации всё равно, пользователям тоже.

                                                      Не проецируйте ваше подгорание на меня, я уже давно ничего не ожидаю от здешних людей, и не испытываю по этому поводу эмоций.
                                                      И опять таки вы не внимательны, я уже писал выше:
                                                      Не знаю как вы, а я считаю иначе, это нормальное поведение когда мужики бросаются сломя голову вступаться за слабый пол, даже не пытаясь вникнуть в ситуацию, человек может и не хотел клеветать на меня, но сами понимаете как это бывает.

                                                      Как можно удивляться чему-то нормальному и привычному?
                                                0
                                                Чисто ради интереса, вы до сих пор не видите ссылку с доказательствами?
                                                Времени прошло достаточно, страсти уже поутихли, интересно как поменяется ваша позиция, и поменяется ли вообще.
                                                  0
                                                  Жаль, ошибки нужно уметь признавать.
                                                  +2

                                                  эээ, что, простите? Вы уж определитесь, кто вокруг вас "плохой".

                                                +3
                                                В Компании работает очень много действительно крутых разработчиков, которые могут практически всё, что угодно. Но вот стоит ли тратить их усилия, чтобы написать свою версию Кафки или пародию на Docker и Kubernetes?

                                                Да, стоит, Docker и Kubernetes работают не настолько хорошо, чтобы их можно было использовать в масштабах Яндекса. Я работал в Яндексе 5 лет, последние 2 года работаю в Авито и смотрю на зоопарк современных Open Source технологий изнутри — их стабильность и качество очень сильно преувеличены.

                                                Как разработчик вы будете вынуждены постоянно разбираться в этих внутренних велосипедах, абсолютно не развиваясь в релевантных для внешнего рынка направлениях. Выйдя через несколько лет за пределы Яндекса, вы рискуете оказаться в неприятной ситуации, когда ваши умения практически ничего не стоят.

                                                Это правда, но не вся — концепции одни и те же, а умение пользоваться конкретной технологией не стоит почти ничего.

                                                Здесь считается нормальным посадить senior разработчика «грепать» логи с нескольких хостов, потому что ELK-стек not invented here.

                                                Насколько я помню, в Яндексе принято возделывать свою делянку, если что-то неудобно, это надо улучшать.

                                                Разработчики каждого сервиса сами отвечают за его функционирование в production’е

                                                Это нормально, представьте на своём месте несчастного админа, который должен чинить ваш велосипед даже не представляя как он работает.

                                                А ещё очень много проектов, которые собираются и запускаются только на Linux.

                                                Это нормально если у вас production на Linux.

                                                Развивать своих сотрудников Компания так же не заинтересована. Никаких индивидуальных планов развития – здесь так не принято. Можешь заниматься чем угодно, но в свободное от работы время.

                                                Я за время работы в Яндексе отучился в ШАД вольнослушателем, это дало безумный буст карьере, из-за чего я собственно и уволился, но это совсем другая история :)

                                                Заключение:
                                                Яндекс — отличная компания, но как и везде, очень много зависит от команды и руководителя — их надо выбирать на собеседовании, это действительно важно.
                                                  +92
                                                  Да, стоит, Docker и Kubernetes работают не настолько хорошо, чтобы их можно было использовать в масштабах Яндекса

                                                  Угу, Амазону с его EKS/ECS подходят, Адидасу для его корпоративного управления медиями подходит — а Яндексу не подходят. Какой такой у Яндекса особый масштаб?

                                                  При том, что вряд ли у Яндекса получится сделать лучше: контейнеризация — это уровень ядра системы. Каков размер команды Яндекса, которая занимается кернелхакингом и системными демонами?

                                                  АФАИК, в Яндекс.Деньгах docker и k8s себя нормально чувствуют без велосипедов. И ELK там есть. Ну то есть на три велосипеда меньше, и как-то ни клиенты этого не ощущают, ни разработчики не расстроены.

                                                  концепции одни и те же, а умение пользоваться конкретной технологией не стоит почти ничего.

                                                  Умение хорошо пользоваться конкретной технологией стоит существенных денег по предложению на рынке. А вот яндекс-only-велосипеды на рынке не стоят ничего. Потому что за пределами Яндекса их нет.
                                                  Потому что если у вас не набита рука на конкретной технологии — вы представляете собой риск деградации перформанса на проекте, особенно если проект горит.

                                                  Насколько я помню, в Яндексе принято возделывать свою делянку, если что-то неудобно, это надо улучшать

                                                  Улучшать трассировку логов на продакшне — это ответственность devops/эксплуатации, а не разработчиков.

                                                  Это нормально, представьте на своём месте несчастного админа, который должен чинить ваш велосипед даже не представляя как он работает.

                                                  Нет. За продакшн отвечает админ/devops/эксплуатация. Разработка отвечает за то, чтобы выкатываться в прод после стейджинга, который по вкусу идентичен продакшену.

                                                  Это нормально если у вас production на Linux.

                                                  Это ненормально, если вы пишете на Java. Если вы пишете на Java — будьте добры писать кроссплатформенно.

                                                  как и везде, очень много зависит от команды и руководителя — их надо выбирать на собеседовании, это действительно важно.

                                                  Ну, во-первых — не везде. Во-вторых — как выбирать, не имея данных на руках?

                                                  А руководство в Яндексе, линейное которое — очень токсичное.
                                                    –8
                                                    Угу, Амазону с его EKS/ECS подходят, Адидасу для его корпоративного управления медиями подходит — а Яндексу не подходят. Какой такой у Яндекса особый масштаб?

                                                    У Яндекса сотни тысяч серверов. У Амазона ещё может быть что-то похожее (к сожалению слабо себе представляю их внутреннюю кухню, они используют своё публичное облако?), про Адидас вообще странно слышать в этом контексте.

                                                    При том, что вряд ли у Яндекса получится сделать лучше: контейнеризация — это уровень ядра системы. Каков размер команды Яндекса, которая занимается кернелхакингом и системными демонами?

                                                    Не помню, к сожалению, кажется человек 10 там было. Справедливости ради, сам Docker — это не уровень ядра, это набор обёрток вокруг интерфейсов ядра, насколько я помню.

                                                    Умение хорошо пользоваться конкретной технологией стоит существенных денег по предложению на рынке.

                                                    По моим наблюдениям скорее ценится богатая эрудиция и умение на месте построить из имеющихся middleware-блоков нужную функциональность.

                                                    Улучшать трассировку логов на продакшне — это ответственность devops/эксплуатации, а не разработчиков.

                                                    К сожалению мне не попадалось компаний где это было бы на 100% так.

                                                    Нет. За продакшн отвечает админ/devops/эксплуатация. Разработка отвечает за то, чтобы выкатываться в прод после стейджинга, который по вкусу идентичен продакшену.

                                                    В победившем мире DevOps это абсолютно не так.

                                                    Это ненормально, если вы пишете на Java. Если вы пишете на Java — будьте добры писать кроссплатформенно.

                                                    Я, к сожалению, не пишу на Java (только на Python, Go и C++), но обычно от backend-разработчика требуется реализовать функциональность, которая будет работать в проде, а не на произвольной архитектуре и ОС.

                                                    Ну, во-первых — не везде. Во-вторых — как выбирать, не имея данных на руках?

                                                    Искать информацию, просить встречи с командой, пытаться понять комфортно ли будет работать с этим тимлидом. В конце концов всегда можно сротироваться в другую команду.
                                                      +1
                                                      Подозреваю, все-таки 100 000 виртуальных серверов, в среднем 1 юнит-сервер 500 Вт, тогда суммарная мощность около 500 МВт. Вся Германия потребляет в среднем 40 000 МВт.
                                                        +12
                                                        Скорее всего вы неверно неверно посчитали энергопотребление серверов, это в основном блейды, у них потребление сильно меньше.

                                                        На 2013 год только в поисковом облаке было около 40000 железных серверов, это было уже 7 лет назад, с тех пор было построено несколько новых датацентров, каждый следующий запаковывался всё плотнее и плотнее.

                                                        Вот неплохой обзор.
                                                          +1
                                                          Сервера 500 давно уже не потребляют. Сотню-две (3 — в упор) в зависимости от нагрузки, если нет GPU и jbod.
                                                          И нет, контейнеров не 100 тысяч, намного больше. Я не помню, сколько я могу сказать, чтобы не нарушить NDA =)
                                                            +2
                                                            два процессора с турбобустом легко потребляют > 400 =)
                                                              –1
                                                              Вопрос в том, каких. Не обязательно покупать десять тысяч процессоров, которые жрут 200+ в прыжке, если они будут менее производительны, чем 15 тысяч других процессоров, которые жрут меньше и стоят дешевле в 2 раза.

                                                              Современные процессоры (особенно не под пиковой нагрузкой) очень экономят электричество. Как-то я поймал thinkpad x1 gen6 с i7-чтототамU за потреблением трёх ватт по acpi. С включенным экраном и wifi. Трёх. А так 8-10. И это нифига не медленный процессор.
                                                                +2
                                                                Вы сравниваете процессор для ультрабука, который троттлится при открытии браузера с серверным процессором? =)

                                                                Посмотрите TDP для современных процессоров Intel. Он там указан без турбобуста ark.intel.com/content/www/us/en/ark/products/series/192283/2nd-generation-intel-xeon-scalable-processors.html
                                                                  0
                                                                  > Вы сравниваете процессор для ультрабука, который троттлится при открытии браузера с серверным процессором? =)
                                                                  Я сравниваю процессор, который на ~20% медленнее ходовых на рынке бюджетных серверов i7 6700/e3-1230 при в три раза меньшем потреблении, а в простое — раз в 20 меньшем.
                                                                  Ничерта он не троттлился, год в powersave простоял. Вот 5xxx — да, тротлится. Так, что музыка с браузера заикаться начинает.

                                                                  > Посмотрите TDP для современных процессоров Intel.
                                                                  Посмотрел, 2660v4 — 105W. Отличный процессор и продаётся на развес.
                                                                  Только зачем смотреть на TDP, если можно посмотреть на реальное потребление серверами?
                                                                    0
                                                                    > Посмотрел, 2660v4 — 105W. Отличный процессор

                                                                    Если базовая частота 2ггц устраивает =)

                                                                    Сейчас проверил 2699v4 на турбобусте — 195 ватт при TDP 145W
                                                                      0
                                                                      Ну вот cpuboss пишет про 2660/2699 typical power consumption:
                                                                      85.31W vs 117.81W

                                                                      Что отлично укладывается в мои слова. И даже если на 2 камня дунуть турбобустом — будет 300 в прыжке.

                                                                      > Если базовая частота 2ггц устраивает =)
                                                                      Частота-то может и не устраивает, но вот ценник в 75 тысяч против 270 заманчив ;)
                                                                      А три с половиной камня 2660 будут в любом случае производительнее, чем один 2699

                                                                      Я уже писал чуть ниже, что рассуждения «2699 лучше» и все подобные хороши только когда серверов несколько штук. Ну может десятков. И место для их установки ограничено, а не достраивается по необходимости.
                                                                      И да, что один сервер будет потреблять полкиловата — да, такое случается, я с этим не спорил. Бывают сервера и с большим количеством сокетов, но это же не показатель что «все сервера потребляют 3 киловатта».
                                                                        0
                                                                        > Ну вот cpuboss пишет про 2660/2699 typical power consumption:
                                                                        85.31W vs 117.81W

                                                                        не знаю что они пишут, но я смотрю сенсоры на реальной машине под нагрузкой с LA 60-70 =)

                                                                        > Частота-то может и не устраивает, но вот ценник в 75 тысяч против 270 заманчив ;)

                                                                        2699v4 нет смысла брать (у него цена неадекватная), т.к. уже два поколения процессоров вышло и за 160-180 тысяч сейчас можно получить больше потоков (48) с большей базовой частотой (2.4). А за 250 тысяч можно получить базовую частоту 3.2 и 32 потока. Но TDP там 205 ватт =(

                                                                        > И да, что один сервер будет потреблять полкиловата — да, такое случается, я с этим не спорил.

                                                                        Я просто ответил на утверждение:

                                                                        > Сервера 500 давно уже не потребляют. Сотню-две (3 — в упор)

                                                                        Серверы разные нужны, серверы разные важны =)
                                                                          0
                                                                          Сколько тепла в вашем ДЦ можно со стойки снять? Какой резон ставить мощные камни, если 40 (ну ок, пусть даже 30) тушек в стойке будут в 2 раза превышать бюджет по питанию и охлаждению, если нормально их прогрузить?
                                                                            0
                                                                            > Серверы разные нужны, серверы разные важны =)
                                                                            Это-то понятно, но ветка изначально про вполне конкретные серверы была )
                                                                          0
                                                                          Да, Интеле сейчас отнял у АМД титул главного по горячим камням.
                                                                        0
                                                                        У меня на даче стоит Lenovo 3550 M4 с 2CPU и 8 HDD SAS 15k под виртуализацией, в среднем кушает 250-300Вт
                                                                    +1
                                                                    сотню-две (3 — в упор) в зависимости от нагрузки, если нет GPU и jbod.
                                                                    современные xeon'ы потребляют 240 ватт, а в серверной машинке их два. Плюс мелочевка типа материнки и оперативы
                                                                      0
                                                                      Не ссорьтесь :) На самом деле, это знают только в конкретном, подчеркиваю, конкретном датацентре. Берут общее энергопотребление за период, делят на количество серверов и т.д. и т.п. Не забываем охлаждение, не забываем про инфраструктуру доставки питания (потери на проводах). Днем загрузка серверов и процессоров в частности больше, ночью меньше, поэтому датацентры дают серьезные скидки тем, кто работает ночами, и потому у Амазона спотовые, т.е. оставшиеся на конкретный момент свободные вычислительные ресурсы стоят в несколько раз дешевле обычных — но, как следствие, у вас нет никакой гарантии, что они будут доступны, скажем, и на следующий день по этой же дешевой цене.
                                                                      А вы сейчас спорите про термопакет сервера, т.е.максимальное количество потребляемой энергии, на которое рассчитываются системы охлаждения и питания сервера. Это совершенно другое, посмотрите на загрузку процессора на вашей собственной машине сейчас, например.
                                                                        0
                                                                        Очевидно, что когда речь идет о масштабных закупках, процессоры выбираются не по принципу «взять самый мощный и жрущий электричество» же =)
                                                                        Нужно соблюдать баланс между ценой, потреблением, производительностью и много чем ещё. Есть достаточно производительные Xeon-ы с в два раза меньшим потреблением электричества.
                                                                          0
                                                                          Смотрят на количество ядер, так как от этого зависит стоимость лицензий. Иногда в сумме дешевле взять быстрые камни с малым количеством ядер
                                                                            0
                                                                            Если речь стоит про лицензии — это уже вряд ли масштабные закупки.
                                                                          0

                                                                          вы все правы. потребление зависит от нагрузки.

                                                                      +46
                                                                      > У Яндекса сотни тысяч серверов. У Амазона ещё может быть что-то похожее

                                                                      Если сложить всех клиентов амазона на EKS/ECS и сам амазон, то там под одну-две сотни яндексов наберется. Сравнивать, конечно, так не очень правильно, но для амазона это как бы единая система.

                                                                      Амазон, кстати, это отличный пример компании, у которой внутри все максимально просто и при этом сильно стабильней чем у облачных конкурентов.

                                                                        0
                                                                        А у вас есть свежие данные про число серверов у Amazon? Я нашёл только несколько устаревшие, там упоминалось про 900к серверов суммарно.

                                                                        Было бы интересно ознакомиться с реальным положением дел :)
                                                                          +1
                                                                          Не знаю на счет количества реальных серверов, облака и kubernetes это не про физические машины. То, что у них очень много клиентов, которым постоянно нужно поднимать по 10000+ воркеров для временных батч-вычислений и все это работает стабильно, является для меня показателем.

                                                                          Не забывайте, что у них в клиентах есть такие гиганты как Netflix, Twich, Twitter, ESPN, Adobe.
                                                                            0
                                                                            Kubernetes в последних версиях поддерживает до 200 подов на одну ноду, в более старых до 100.

                                                                            10000 инстансов — это не очень много на самом деле, всего около сотни серверов, это зависит от их размера конечно.
                                                                              0

                                                                              А вы уверены, что у них эти воркеры работают в Kubernetes? У меня, к сожалению, нет под рукой подробной информации об их инфраструктуре. Если вы в курсе — было бы интересно послушать.

                                                                                +6

                                                                                AWS EKS это как раз k8s в облаке.
                                                                                Но справедливости ради, для AWS Lambda они использовали Firecracker, т.к. изоляция докера их не устроила, а традиционные виртуалки слишком тяжёлые.

                                                                          +2
                                                                          к сожалению слабо себе представляю их внутреннюю кухню, они используют своё публичное облако?

                                                                          Оооооо! Мало того, их философия гласит: «Мы делаем в первую очередь для себя, что-бы нам было удобно и круто, и только потом для клиентов.». Не дословно конечно, но это очень важный момент.
                                                                          Я знаю так как работаю в одной команде с чуваком который работает в амазоне.
                                                                            0
                                                                            это довольно позорный комментарий от человека, 5 лет проработавшего в Яндексе.
                                                                            +10
                                                                            Умение хорошо пользоваться конкретной технологией стоит существенных денег по предложению на рынке. А вот яндекс-only-велосипеды на рынке не стоят ничего. Потому что за пределами Яндекса их нет.
                                                                            Потому что если у вас не набита рука на конкретной технологии — вы представляете собой риск деградации перформанса на проекте, особенно если проект горит.


                                                                            Косвенно могу подтвердить свою точку зрения тем, что крупные компании не требуют знания конкретных технологий у кандидатов, только знания языка и концепций: Amazon, Google, Facebook.
                                                                              +55
                                                                              Потому что у них внутри свои велосипеды…
                                                                                +3
                                                                                Только их велосипеды — часто стандарт в отрасли. У яндекса с выкаткой велосипедов в стандарт отрасли пока все сложнее.
                                                                              +17
                                                                              Это ненормально, если вы пишете на Java. Если вы пишете на Java — будьте добры писать кроссплатформенно.

                                                                              Зачем это делать и тратить на это ресурсы? Какую проблему это решит?
                                                                                +6

                                                                                Это ничего не стоит, если умеешь. Это чисто организационный момент.
                                                                                А решает целый ряд проблем — и качество кода поднимает, и найм людей упрощает, когда каждый может выбрать себе ту систему, которая нравится

                                                                                  +16
                                                                                  Я не уверен в этом. Допустим, есть некоторая библиотека, которая вызывает какой-нить sendfile или inotify через JNI. Очевидно эта библиотека не кросплатформенная, и все что от нее зависит тоже. Чтоб сделать это кроссплатформенным нужно будет городить странный никому не нужный код, который никогда не будет запускаться и еще поддерживать его.
                                                                                  Я когда давно работал в Яндекса, там была противоположная хрень. Был малекний кусок какого то С++, который собирался под винду, толи Яндекс бар, то ли что-то такое. И из-за него весь репозиторий тоже должен быть быть таким. Хотя там был библиотечный код для бэкэнда, 99.9% которого никто и никогда не будет запускать под виндой, кроме этого мелкого куска. В итоге все разработчики делали все, чтоб их код только не попадал в этот репозиторий и можно было нормально использовать очень полезные gcc расширения и всякие linux-специфичные API без глупых заморочек.
                                                                                  качество кода поднимает

                                                                                  Лишние уровни абстракций или условная компиляция сомнительное улучшение кода.

                                                                                  найм людей упрощает

                                                                                  Реально кто-то может не принять офер или уволиться узнав, что какой-то кусок кода нельзя запустить по его любимой windows rt?
                                                                                    +19

                                                                                    Я бы реально отказался от оффера если бы узнал что не смогу полноценно разрабатывать под линуксом (и не один раз это делал).

                                                                                      0
                                                                                      Аналогично. Разработка под windows — это боль, превращающая программирование в страдания.
                                                                                      +8
                                                                                      Допустим, есть некоторая библиотека, которая вызывает какой-нить… или inotify через JNI. Очевидно эта библиотека не кросплатформенная, и все что от нее зависит тоже


                                                                                      Кому очевидно?
                                                                                      Очевидно что эта библиотека кросплатформенная и называется JDK. Ибо функции inotify в Java выполняет WatchService.

                                                                                      Откройте какой-нибудь условную обёртку над нативыми библиотеками, например Xerial и удивитесь на скольких платформах она работает

                                                                                      Mac\x86_64\libsqlitejdbc.jnilib
                                                                                      FreeBSD\x86_64\libsqlitejdbc.so
                                                                                      Linux\aarch64\libsqlitejdbc.so
                                                                                      Linux\android-arm\libsqlitejdbc.so
                                                                                      Linux\arm\libsqlitejdbc.so
                                                                                      Linux\armv6\libsqlitejdbc.so
                                                                                      Linux\armv7\libsqlitejdbc.so
                                                                                      Linux\ppc64\libsqlitejdbc.so
                                                                                      Linux\x86\libsqlitejdbc.so
                                                                                      Linux\x86_64\libsqlitejdbc.so
                                                                                      Windows\x86\sqlitejdbc.dll
                                                                                      Windows\x86_64\sqlitejdbc.dll
                                                                                        +2
                                                                                        Очевидно что эта библиотека кросплатформенная и называется JDK. Ибо функции inotify в Java выполняет WatchService.

                                                                                        Вообще-то, с WatchService всё не так хорошо. Например, иногда в Windows она норовит на файлы повесить share mode при котором другие процессы ничего с этими файлами сделать не могут. Потом в том, как приходят события в WatchService, в Windows есть свои интересные нюансы (не помню точно, какие, сталкивался с этими особенностями пару лет назад).


                                                                                        Откройте какой-нибудь условную обёртку над нативыми библиотеками, например Xerial и удивитесь на скольких платформах она работает

                                                                                        А если нет такой условной обёртки? Или условная обёртка не подходит под нужды? Ну например, разместить text input поверх GL окна, при этом имея полный доступ к конфигурации GL-контекста этого окна? К сожалению, ни SDL, ни GTK этого делать не позволяют, так что то, что в Windows решается штатным Windows API, в Linux делается за счёт продирания через особенности интеграции GTK с wayland или X.org.

                                                                                          +1
                                                                                          Ну тогда if… else помогают.
                                                                                          Ньюансы это всё таки-лучше чем вообще не рабоающий функционал.
                                                                                          Если мне надо будет протестировать этот конкретный кейс, то можно и виртуалке запустить, но если я работаю над чем-то другим, то я могу использовать мою любимую ОС в разработке и не париться о деталях
                                                                                            +1

                                                                                            Ну так написание, отладка, тестирование и поддержка этих if...else — это человекочасы, которых в конкретном случае может и не быть. Видимо, люди сопоставили тот факт, что у большинства и так linux или macos, а поддержка windows выйдет дороже, чем перевод на linux/macos тех, кто предпочитает windows.

                                                                                              0
                                                                                              Может это и так в каких-то других языках программирования, но это явно не про джаву.
                                                                                              Странно что вы osx и линукс в корзину кладёте. Это вообще-то разные системы. И большинства таки либо Windows либо OsX

                                                                                                0
                                                                                                Может это и так в каких-то других языках программирования, но это явно не про джаву.

                                                                                                Ну скажем так, дьявол в деталях. В Java действительно всё с этим очень хорошо, но порой можно попасть в какие-то те самые 0.01% случаев, где начнётся ад.


                                                                                                Странно что вы osx и линукс в корзину кладёте. Это вообще-то разные системы. И большинства таки либо Windows либо OsX

                                                                                                Я ссылаюсь на статью автора, где указано, что проект заводится под Linux, с трудом — под Mac и вообще без надежд — в Windows. Что там у большинства в Яндексе, я могу только гадать, и вообще, не зная их реалий не могу сказать, почему так. Я лишь называю одну из возможных причин.

                                                                                                  +2
                                                                                                  OK, про OsX понял, а вот про 0.01% случаев, когда ад начинается, интересно узнать примеры кейсов.

                                                                                                  Ведь, в большинстве случаев, нам просто требуется включить несколько нативных библиотек и вызывать нужную, проверяя ОС.
                                                                                                  Как в общем-то все эти Java -wrapper-ы и делают
                                                                                                    +3
                                                                                                    а вот про 0.01% случаев, когда ад начинается, интересно узнать примеры кейсов.

                                                                                                    Ну вот простой пример — использовали Apache Spark (написан на Scala) из Java приложения.

                                                                                                    Обнаруживаем, что при запуске под Windows после выхода он не удаляет временные файлы, вообще. Так как у нас Big data после десятка перезагрузок легко было полностью исчерпать все место на сервере.

                                                                                                    Разбираемся, выясняется — баг в Spark'е — он пытается удалять временные файлы, забыв их закрыть в другом треде. Linux'у — пофиг где что открыто, ему сказали удалить — он удалил (точнее файл-то для того процесса остался, но в системе его уже не видно). Windows — просто не удаляет такие файлы.

                                                                                                    Казалось бы — небольшая разница в поведении, а сервер на Windows, мог исчерпать всю память и упасть до того как кто-то что-то заметил.

                                                                                                    К счастью, у нас не было ни одного клиента с сервером на Win в тот момент, поэтому мы просто отправили PR в Spark и забили.

                                                                                                    А представьте ситуацию, когда мы вообще бы не тестировали на Win, а потом резко решили собрать приложение под Win — там каждый неправильный файловый дескриптор или неверная кодировка — превратиться в проблему.
                                                                                                    И это я еще не говорю о статическом подключении С++ библиотек со всякими распознавания изображений и т.п. вещами, у которых просто нет версий для Win, к примеру.
                                                                                                    +1
                                                                                                    Я ссылаюсь на статью автора, где указано, что проект заводится под Linux, с трудом — под Mac и вообще без надежд — в Windows
                                                                                                    вообще как показывает моя личная практика нет смысл заводить под mac/windows вообще ничего (ну, кроме приложух типа ябраузера, но автор очевидно не из той команды). Локально я собираю только протобуфы, чтобы подсказки IDE работали. А код запускаю на дев-сервере
                                                                                                      –1

                                                                                                      Ну а как же скорость сборки? Дев сервер на CI собирается? Сколько времени на это уходит? А как насчёт того, что IDE пересобирает только изменившиеся файлы (например, 1 из 100К файлов в проекте)? А как насчёт того, что некоторые известные нашлёпки на IDE умеют ещё и редеплой делать очень быстро?

                                                                                                        0
                                                                                                        Сколько времени на это уходит? А как насчёт того, что IDE пересобирает только изменившиеся файлы (например, 1 из 100К файлов в проекте)?
                                                                                                        изменившиеся файлы отслеживает не IDE, а система сборки, и пересобираются точно так же только изменения. А сервер с парочкой xeon'ов собирает явно быстрее чем ноутбук с i5.
                                                                                                          +2

                                                                                                          Если вы про Яндекс, то вся эта радость, на сколько я знаю, для Java не подходит. И чтобы только сгенерировать проект для Idea приходится минутами ждать (локальную) компиляцию протобуфов вместе с protoc и другим туллингом. Да и с C++ вы, как мне кажется, приукрашиваете и не говорите о проблемах. Например, распространённая среди коллег плюсовиков практика рефакторинга седом для меня является признаком наличия таких проблем.

                                                                                                    0
                                                                                                    Почему — странно? Обе — POSIX, обе под капотом имеют разные вариации на тему Berkeley System V.
                                                                                                      0
                                                                                                      И большинства таки либо Windows либо OsX
                                                                                                      в яндексе линукс популярнее винды. Вообще (моё личное мнение) винда для разработки удобна тогда и только тогда, когда вы разрабатываете исключительно под винду.
                                                                                                  0
                                                                                                  С настолками, действительно, возня, но условный вебчик на джаве пишется так, что можно гонять отдельные сервисы локально без каких-то проблем. Понятно, что на серваках может быть докер, мониторинг и всякие прокладки, но локально дернуть main-класс ничего не мешает.
                                                                                                  0

                                                                                                  Ну я не имел ввиду части JDK. А что-то очень специфичное сделанное под конкретные требования. Такое есть про многие системные вызовы, они отличаются друг от друга и когда их засовывают в общий интерфейс они теряют что-то.

                                                                                                +2

                                                                                                testcontainers под винду нормально работает? небось только с WSL и какими-нибудь костылями. Но под WSL сейчас, наверное, можно почти что угодно завести, только чем это от разработки под линукс отличается? Не говоря уж о том, что во многих не тривиальных мейвеновских-гредловских проектах будет кроме java куча скриптов на каком-нибудь баше, поддерживать которые под виндой больно и не нужно.

                                                                                                  +1

                                                                                                  Нормально работает, без всяких проблем. Только докер поставить надо :)

                                                                                                    0

                                                                                                    А докер под виндой сейчас разве не через wsl работает?

                                                                                                      0

                                                                                                      нет

                                                                                                        0
                                                                                                        Недавно выпустили WSL 2, в докере тоже появилась его поддержка.
                                                                                                          0
                                                                                                          только памяти он жрет капец, как собственно и wsl1, это всеравно гдето внутри виртуалка у него
                                                                                                            0
                                                                                                            wsl1, это всеравно гдето внутри виртуалка у него

                                                                                                            У первой версии нет виртуалки, а драйвер занимает пару сотен килобайт.
                                                                                                              0
                                                                                                              да, я чёто попутал походу (с докером виндовым)
                                                                                                          0

                                                                                                          Скорее всего, работает так же как под макос: на уровне ядра системы запускается легковесная VM, которая автоматом транслирует часть системных вызовов Linux в системные вызовы windows

                                                                                                        0

                                                                                                        Попробую еще WSL2. Но моя попытка работать с WSL убилась об отсутствие поддержки tun интерфейсов. А VPN заказчика подразумевает их использование для подключения к инфраструктуре. Так что далеко не всё там идеально.

                                                                                                      +3

                                                                                                      Ну как бы лучше (продуктивнее и с меньшей болью) запускать и отлаживать код на своём PC, а не где-то на сервере.
                                                                                                      Конечно, можно обложиться настройкой удалённого доступа в ide, подключаться по ssh и использовать что-то для синхронизации, но это всё требует внимания и служит дополнительными точками отказа. Из проблем — ide для индексирования проекта нужен нормальнный быстрый доступ к файлам и хаки типа "клонировать код и на PC и на сервере и потом как-то синхронизировать" не очень удобны.

                                                                                                        +6
                                                                                                        Я когда работал в Яндексе лет 10 назад, при всем желании локально ничего внятного запустить просто не выйдет никак из-за отсутствия гигабайт нужных данных и доступа к нужным серверам. То есть от силы что-то простейшее вроде hello world. Более того локально оно компилироваться будет ну очень неторопливо.
                                                                                                          0

                                                                                                          А всякие тестовые базы с гигабайтами нужных данных? И завязываться на них при локальном запуске

                                                                                                            +1
                                                                                                            Когда я работал объемы, софт и железо были такое, что чтоб что-то читать вменяемое из этой БД к ней нужно только локально конектиться. Иначе это занимало ну очень долго все. Наверное можно было как-то держать особо маленкие, специально подготовленные базы для быстрого тестирования. Но ни у кого на это не было времени, тк мы тогда росли примерно по 70-100% в год и постоянно нужно было что-то делать, чтоб текущую архитектуру на перле и MySQL приспособить под новые реальности. MySQL в основном использовался как тупой хранилищи из-за объемов. Все join и всякие агрегации делали в коде, тк это работало на порядок быстрее.
                                                                                                            У нас были специальные разработчиские сервера с сотнями гигов памяти и десятками ядер, настроенной репликаций данных. Чтоб подобную полную разработку сделать локально потребовалось бы немало ресурсов людских, который тогда не было.
                                                                                                          +3
                                                                                                          Что-то я не совсем понял. А в чем проблема просто разрабатывать в linux софт, который будет потом работать под linux? И не надо никаких удаленных доступов и синхронизаций. Еще и контейнеры нативно.
                                                                                                            +2
                                                                                                            Потому что с точки зрения только устроившегося в Яндекс топикстартера успешный столичный программист должен быть с Mac'ом ;-)
                                                                                                              +3
                                                                                                              Если бы. Успешный столичный программист, судя по всему, разрабатывает на винде :)
                                                                                                              0
                                                                                                              Ну под винду есть удобные IDE (VS) и другой удобный софт.
                                                                                                              Винда — популярное ентерпрайз решение как тонкий клиент.

                                                                                                              Альтернативы в Линукс конечно есть, но не могу сказать, что они полностью перевешивают по удобству работы.

                                                                                                              Удаленные доступы и синхронизации конечно надо, особенно сейчас.
                                                                                                                0

                                                                                                                Я поэтому и выбрал мак (вместо линукса) — на маке есть вменяемый офис и аутлук. Что для Корп мира, ну, прям очень как важно. Но либо у Яндекса есть свои велосипеды вместо офисного пакета и органайзера, либо на роли обычного разработчика они не нужны вовсе

                                                                                                              0
                                                                                                              Запускать и отлаживать локально программу, которая в продакшене работает на серверах с 56\80 ядрами и 256\512 Гб памяти конечно можно (в каком-нибудь усечённом варианте), но очень не удобно.
                                                                                                                –4
                                                                                                                Запускать и отлаживать локально программу, которая в продакшене работает на серверах с 56\80 ядрами и 256\512 Гб памяти конечно можно (в каком-нибудь усечённом варианте), но очень не удобно.

                                                                                                                Извините, но это чушь. Вы слабо представляете себе современную разработку.

                                                                                                                  +4
                                                                                                                  Ну как слабо представляю. Я как раз такой сервис разрабатываю. Слепок одного шарда продакшен данных занимает почти целиком сервер с 256 Гб. Конечно мы умеем делать миниатюрную копию такого шарда с искуственными данными, но достаточно часто требуется именно полноценная версия. На ноутбуке это провернуть невозможно.

                                                                                                                  Я некоторое время участвовал в разработке одного сервиса-сателлита MS SQL и там вся разработка велась на рабочей станции, естественно под Windows. Мне не понравилось. MSFT не экономит на оборудовании, но если у клиентов характерные размеры баз по 50-1000Гб, а у тебя десктоп с 32Гб RAM, то это создаёт неудобства. Всё равно приходилось пользоваться виртуалками, только ещё и с RDP вместо консоли. Ну и скорость компиляции (если нужно локально собрать) оставляла желать лучшего.
                                                                                                                    +1
                                                                                                                    Слепок одного шарда продакшен данных занимает почти целиком сервер с 256 Гб.

                                                                                                                    Так а в чем проблема сам код развернуть локально, и просто подключаться к рабочей БД тоже локально?
                                                                                                                      –1
                                                                                                                      Ну как минимум потому что нет никакой БД.
                                                                                                              –2
                                                                                                              Зачем это делать и тратить на это ресурсы? Какую проблему это решит?

                                                                                                              Эээээ, писать на языке, который спроектирован кроссплатформенным — кроссплатформенно? Ну я даже не знаю, что ответить. Следовать идеологии и практикам языка, не?

                                                                                                              Переформулирую — зачем тащить в Java-решение нативный код, который делает его (Java-решение) некроссплатформенным?
                                                                                                                +2
                                                                                                                А разворачивать вы это ручками будете? Есть много вещей под который нужно свои обёртки для установки/разворачивания делать. И трудоёмкость там улетает в небеса, если кросплатформенность делать.
                                                                                                                Аналогично со сложной сборкой. Если вам нужно на выходе exe-файл получить, то очень интересно становится.
                                                                                                                Аналогично со всякими нестандартными технологиями. Допустим, вам нужно с видео работать. Ну, блин, напишите это на Java без нативного кода, да ещё и кросплатформенно.
                                                                                                                  0
                                                                                                                  exe получить как раз не проблема. Для этого есть launch4j. unix-бинарник — ещё проще.
                                                                                                                    0
                                                                                                                    Есть-то он есть, но сделать сложную автоматическую там тот ещё квест. Особенно если нужно разные программы из одного дерева исходников делать.
                                                                                                                    А иметь разные linux и windows билд-сервера с разными система сборки — незабываемое удовольствие. И сборку можно бы сделать под под wine, но это квест.
                                                                                                                    Собирать исполняемые файлы под linux проще, но тоже интересно — особенно же хотим, чтобы там всякая автоматизация была, ошибки внятные выводились, версия доступна была и т.п. А если мы этого не хотим, то мы криворукие уродцы.
                                                                                                                    А ещё кроме exe нужно если некий исталлятор делать и что-то для разворачивания под Linux (а если у нас несколько дистрибутивов...)
                                                                                                                    И вот это всё сделать и поддерживать ради смелого утвреждения, что раз язык кроссплатформенной, то нужно всё писать кроссплатформенно?
                                                                                                                      0
                                                                                                                      Нет никакого квеста. Всё прекрасно собирается как мавеном так и граделом за один проход и одной командой. Никаких разных систем сборки не надо. Для launch4j формально требуется windows, но можно обойти это ограничение, если приспичит.

                                                                                                                      Нам по сути надо либо shell -скрипт приконкатенатить к fat-jar-у либо exe-шник который запускает сам себя как java -jar . Все эти trap-ы и проверку версий пишете внутри shell скипта.

                                                                                                                      Кроме того, вроде как в последней джаве сделали какой-то упаковщик.

                                                                                                                      Если нужен rpm — используете redline rpm, если msi — wix плагин для мавена (ну здесь уже без Windows билдера походу не обойтись)

                                                                                                                    0
                                                                                                                    А разворачивать вы это ручками будете?

                                                                                                                    А при чем тут «разворачивать»? Если вы пишете на Java вещь, которая так себе разворачивается что под Windows, что под Linux — вы выбрали не тот язык, не тот фреймворк, и не то средство решения задачи.

                                                                                                                    И трудоёмкость там улетает в небеса, если кросплатформенность делать.

                                                                                                                    Это смелое утверждение, и оно требует доказательства. Или хотя бы описания сценария — что это за софт, почему он за собой тянет что-то платформенное, и почему это платформенное нельзя подтянуть ко всем мейнстримным платформам. С TdLib, например, таких проблем нету — его просто пересобрать под целевую платформу и дернуть из нужного места загрузку нативной либы.

                                                                                                                    Если вам нужно на выходе exe-файл получить, то очень интересно становится.

                                                                                                                    Смотрим первый пункт, про целесообразность средства разработки.

                                                                                                                    Допустим, вам нужно с видео работать. Ну, блин, напишите это на Java без нативного кода, да ещё и кросплатформенно.

                                                                                                                    Вы не поверите — буквально полгода назад ушел из стартапа, который активно переваривал видюшечки, и все там было на джаве (точнее на Котлине, но не суть).
                                                                                                                      +1
                                                                                                                      А при чем тут «разворачивать»? Если вы пишете на Java вещь, которая так себе разворачивается что под Windows, что под Linux — вы выбрали не тот язык, не тот фреймворк, и не то средство решения задачи.

                                                                                                                      Угу. А какие у нас есть кроссплатформенные средства, которыми нужно решать таки езадачи? Java — говорите, что нет. Python? аналогично и те же проблемы, что и у Java. C++/Qt — ОФИГЕННО ДОРОГО, долго и сложно и на выходе, мы вместо одних проблем получаем вагон других. Так себе размен. .NET — те же проблемы, что у Java, но больше, хуже и в обратную сторону. И получаем… Что такие задачи решать не нужно? Интересно.

                                                                                                                      Вы не поверите — буквально полгода назад ушел из стартапа, который активно переваривал видюшечки, и все там было на джаве (точнее на Котлине, но не суть).

                                                                                                                      Тогда вы должны понимать проблемы кроссплатформенной разработки.
                                                                                                                        0
                                                                                                                        Тогда вы должны понимать проблемы кроссплатформенной разработки.
                                                                                                                        Может они только на андроид их разворачивали :)
                                                                                                                    0

                                                                                                                    Я думаю для этого были причины. Возможно производительность, возможно проще код без лишних абстракций и реализаций под все случаии какой-то библиотеки.
                                                                                                                    Писать кроссплатформенно, наверное хорошо, но это вероятно не особо поможет решить проблемы бизнеса. Для каких то случаев это может потребовать много ресурсов.

                                                                                                                +26
                                                                                                                чтобы их можно было использовать в масштабах Яндекса.

                                                                                                                А какие масштабы в Яндексах?
                                                                                                                Их продуктовые направления проигрывают многим американским стартапам, как по объёму, так и по качеству. Странно слышать, что локальный продукт требует более масштабных масштабов, чем глобальный… мы же всё таки не в Китае или Индии.

                                                                                                                  0
                                                                                                                  Я ответил выше, у Яндекса сотни тысяч серверов.
                                                                                                                  На таких масштабах различие в 10% производительности — огромные деньги.
                                                                                                                    +4

                                                                                                                    Мой вопрос был не про количество серверов :)

                                                                                                                      +14
                                                                                                                      А про что тогда? :)
                                                                                                                      У Яндекса действительно очень большая инфраструктура, таких в мире может быть пара десятков, завязываться на свои технологии — это удобно, почти все крупные игроки так делают.

                                                                                                                      Kubernetes — это продукт на основе внутреннего продукта Google, Zookeeper родился в Yahoo, Cassandra в Facebook, MongoDB в 10gen и так далее, очень многие из активно используемых сегодня технологий так или иначе зародились как внутренние продукты в разных компаниях.
                                                                                                                        +17

                                                                                                                        У вас почему-то аксиомой является тезис, что Яндекс — большой. Вот я у вас и спрашиваю — как может быть большой компания, которая так и не вышла на глобальный рынок и эффективно работает только на локальном, который в максимуме может дать всего 230 миллионов пользователей.

                                                                                                                          +3
                                                                                                                          Видимо потому что я там работал и знаю, что он большой? Меня напротив удивляет ваше стремление считать Яндекс априори маленьким :)

                                                                                                                          А что для вас большая инфраструктура?
                                                                                                                            +4
                                                                                                                            Меня напротив удивляет ваше стремление считать Яндекс априори маленьким :)

                                                                                                                            Интернет компания считается большой, если у нее много пользователей или же хороший потенциал роста.


                                                                                                                            Например, в Netflix на Q1 2020 — 182 миллиона активный пользователей, и если я правильно помню, за время пандемии они таки пробили 200кк юзеров. А вот у Яндекса с их кинопоиском нет даже гипотетических шансов приблизиться к этим цифрам.


                                                                                                                            И по всем остальным продуктам — тоже самое.

                                                                                                                              –2

                                                                                                                              Похоже только для Вашего уровня он большой.

                                                                                                                                +6
                                                                                                                                Так он в абсолютных величинах большой. Или для вас большой — это когда серверов не меньше миллиона?

                                                                                                                                Мне кажется с точки зрения разработчика капитальной разницы между условными 100к и 1кк нет.
                                                                                                                                  +1

                                                                                                                                  Размеры — они относительны вообще. Земля большая или маленькая? Ну вот смотря с чем сравнивать.