Я уволился из Яндекс.Маркета, отработав там почти 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.
ne555
Спасибо, итересно было почитать, сейчас уже на новом месте? Как оно там?
Что-то знакомое, думаю.
Как я проработала 3 месяца в Я.Маркете и уволилась
Про Брингли мало деталей к сожалению.
IvanVakhrushev Автор
Да, уже на новой работе. Пока очень динамично — огромное количество новой информации.
Про Брингли, если честно, не хочется говорить. Я помню свой первый день в Яндексе, 05 марта 2019, как сидел в Мулен Руж (конференц-зал) и слушал про трансграничное направление Маркета. Уже тогда было понятно, что оно не полетит. Идея строилась вокруг брендированной одежды и обуви из Турции… Ну такое… Стоимость логистики + турецкий подход к бизнесу всё убили. А конкурировать с АлиЭкспресс на товарах из Китая нереально.
crmMaster
Крупные компании прощупывают ниши, это нормально. Но сваливать на разрабов проблемы маркетинга это низко, подобное можно ждать от шаражки с взбаломошным директором, но никак от крупной компании.
InterceptorTSK
И второе — «кто-то там» сказал, что ожидания болельщиков — это проблемы болельщиков. Это я про то, что если кто-то там шибко обольщался, ну так это проблемы того кто обольщался. Не более того.
crmMaster
Есть конкретные критерии крупного бизнеса — доход более 2 млрд руб, количество работников — более 251 человек. Яндекс под эти критерии подходит. Так что это не я взял, это общие критерии для РФ, могли бы и погуглить, а не задавать глупых вопросов.
И про болельщиков я не понял — что вы этим хотели сказать? Если для вас норма сваливать на разрабов менеджерские просчеты, то идите в… Яндекс, там такое цветет и пахнет.
В нормальных компаниях за завершенный и работающий проект, даже если он не пошел по каким-то причинам, исполнителей премируют. Не должен исполнитель отвечать за промашки руководства, он наемный работник, а не бизнес партнер.
Over-9000
+1
F0iL
А где обман-то?
8854 > 251
754млн USD ~ 51млрд. RUB > 2млрд. RUB
Over-9000
Извините, не так прочитал.
Neusser
8854 больше, чем 251.
745 млн долларов больше, чем 2 млрд рублей.
Разве не так?
Xobotun
А что было в оригинальном коммаентарии, если кто помнит? Сейчас там
+1.F0iL
Комментатор обвинил комментатора во вранье, но ошибся сам :)
Over-9000
Привёл доказательства правоты автора.
А комментарий следовало писать под предыдущим постом.
ad1Dima
Комментатор неправильно прочитал коммент на который отвечал, решил что в нем озвучены не критерии большой фирмы а количество людей и доход Яндекса. И весьма прямолинейно обвинил автора во лжи.
InterceptorTSK
Хм… Сколько злобы. :))) А зачем?
Ниже строка.Итак, что вам даёт число? Скорее всего чуть менее чем ничего. Число никак не раскрывает экономическую модель бизнеса. Для маразматичного налоговика число может быть что-то там да и даёт, но вменяемым — вряд ли…
Бизнес как водится трёх видов бывает. Мелкий, средний и крупный. Критерии сего определяются вовсе не какими то там числами, а экономическими моделями. Про мелкий смысла нет говорить, с ним всё понятно. Средний — это когда дело доросло до вменяемого размножения самого себя. Крупный — это средний + производство базовых «орудий труда» для дела. Само собой это всё слишком грубые критерии, если нужны более чёткие — учебник экономики откройте, а не налоговый кодекс, или что там вы открыли от рашенских маразматиков — тут уж я понятия не имею…
И да, яндыкс — это средний бизнес, торгующий гавённой третьесортной рикламкой вразнос. Не более.
Причём заметьте, яндыкс является средним бизнесом даже с небольшой натяжкой вообще-то…
ad1Dima
И Яндекс по ваше определение точно подходит :)
InterceptorTSK
Не знаю зачем яндыксу «велосипеды». Это у яндыкса спрашивать нужно.
«Орудия труда» в данном случае — это операционки, браузеры, всякие ноды, серваки и всё то, что базово помогает яндыксу далее создавать «продукты», продающие рекламу. Это и есть «орудия труда». Первоначальные экономические зависимости.
Ой простите. Это не про яндыкс. Ахаха! :)
А у яндыкса похоже что да, только калешные монструозные виласипеды… Тут вы возможно правы.
пс: Сбоку Хабра подкинула «совершенно случайно»: «Google делает свой процессор, а AMD готовится уничтожить Qualcomm». Конечно же это просто совпадение, не более.
crmMaster
В путаете причину и следствие. То что вы назвали — это следствие укрупнения бизнеса. И яндекс по вашему же определению — крупный.
И если уж говорите «посмотри в учебниках» — то давайте ссылки, где это написано, чтобы я ознакомился с полным текстом, а не вашей интерпретацией, которая в корне не корректна.
И если вас не устраивают рашенские маразматики, то в ЕС критерии крупного бизнеса — более 250 человек, а также более 50 млн евро или общим балансом 43 млн евро.
Может если кругом маразматики, то маразматик — это вы? Особенно мне понравилось «торгующий гавённой третьесортной рикламкой вразнос». Смешно. Сам этот маразм выдумал?
cjaushe4ka
Joom?
Hay
Прошу не распространяйте этот фейк, тамошнего автора разоблачили: habr.com/ru/post/470337/#comment_20721735
К тому же она дискредитировала Хабр в глазах IT-сообщества, показав как легко заручится поддержкой, если ты женщина, вскружив мужской части сообщества голову, т.к ранее был аналогичный пост от лица мужчины, где большинство комментаторов его загнобила, жестко загнав в минуса, и даже вынудив его покинуть хабр, а в случае с Юлией несмотря на одинаковые повестки, попросту носили на руках.
Newbilius
Эм… но вот прямо здесь и сейчас публикация от лица мужчины (вроде). Пересечение по отдельным моментам этой и той статьи есть. И эта статья в плюсе. Может дело всё-таки было не в поле автора, а в содержании статьи и подаче материала? Одни и те же факты можно описать и так, что уйдёшь в глубокий минус, и так, что на руках будут носить.
Hay
Честно говоря я не оригинальную пост о которой упоминаю, об этом писал человек в комментариях, но читая многие статьи на хабре еще давно заметил, что отношение сильно зависит от пола, если это мужчина, то «сам виноват, думать надо было», если девушка, то «не переживайте вы так» и всё в таком духе, но суть не в этом.
И дело как раз таки в поле автора, иначе как объяснить то, что у 90% хаброчан просто отключались критическое мышление, и даже когда им открыто демонстрируют факты, они принимаются спорить или оправдывать автора, скажите мне как, как это возможно? Разве это не отличительная черта сильного пола, щелкать в голове рубильником, при виде слабого?
Вполне возможно что того автора загнобили за дело, но это лишь очередная наглядная демонстрация того, что если автор мужчина, то люди не верят на слово, не бояться быть прямолинейными и высказывать своё мнение, а посмотрите на пост Юлии, 90% попросту поверили на слово, принялись утешать, шутить, пытаться разрядить обстановку, и даже спорить с разоблачителями, какой контраст однако.
Впрочем не удивительно, ведь женщины в IT редкость, что только повышает их ценность в наших глазах.
Newbilius
Два человека написали статью на одну и ту же тему. Обе в плюсе. Но вы говорит, что
Я правильно понимаю вашу мысль? о_О
ABBAPOH
Те, кому нравилось работать в Яндекс.Маркете, не пишут такие статьи=)
Кто плюсует мне тоже интересно. Это достаточно забавно и интересно читать, но всё же ценность таких статей околонулевая (ИМХО) по сравнению с техническими статьями.
Ну вот прочитает человек такую статью, решит что Яндекс говно и не пойдет туда. Кому от этого лучше? Человеку, который не получит полезный опыт создания scalable систем? Яндексу, который не получит (возможно) ценного сотрудника?
siziyman
Очевидно, человеку, который не пойдёт и не разочаруется в компании сам (если он прочтёт статью и поймёт, что разочаровался бы).
А полезный опыт создания масштабируемых систем можно далеко не только в Яндексе получить.
nin-jin
Прежде всего самому Яндексу. Чем больше нашумит статья, тем больше вероятность, что высшее руководство с ней ознакомится и предпримет какие-либо меры. Без такой обратной связи компания собственно и докатилась до текущего состояния. В Яндексе, собственно, политика такая вместо того, чтобы строить внутренние процессы так, чтобы не было стыдно, если вдруг что-то станет достоянием общественности, — там бьют по башке всех, кто хотя бы минимально проявит свою нелояльность.
ABBAPOH
Я работал в каком-то другом маркете и ничего подобного описанному в статье у нас не было. Либо всё за 2 года ТАК испортилось, либо автор слегка (совсем чуть-чуть) преувеличивает проблемы.
Представим теоретическую ситуацию что в статье — ложь. Что должно делать руководство в этом случае? Ну проведут они расследование, выяснят, что переработок нет или почти нет, статический анализ есть и на венде люди прекрасно работают, а человек просто обиделся на что-то, вот и пишет всякое. А потом другой человек прочитал это и не пошел работать в Яндекс, основываясь на недостоверных/неполных данных. Кто в этой теоретической ситуации выиграл?
Вы это говорите на основании собственного опыта?
nin-jin
Ну, представлять-то можно много чего. Например, что всё именно так как автор и написал, или даже всё на самом деле ещё хуже, но руководство не в курсе.
Агась.
ABBAPOH
Да даже бывшие/нынешние сотрудники Маркета (вроде меня) не в курсе происходящих ужасов, что уж о там о руководстве говорить=)
Мой изначальный поинт в том что не надо принимать на веру всё что пишут в интернетах и автор может быть (скажем мягко) не совсем объективен.
Да, во всякую дичь легче поверить — я когда читал всё это поймал себя на мысли «ну нихрена себе там у джавистов», но, поразмыслив, всё же решил, что слова автора надо делить примерно на 10. Например его поинт про то что на маке/венде не собирается разбивается о то, что это и не нужно делать ибо неудобно — яндексовая система сборки позволяет собирать удаленно на (линуксовых) серверах. Зачем собирать 2 часа утилиту если можно собрать ее за 10 минут на сервере? Опять же, когда я устраивался я всё это выяснил заранее и не стал брать Мак (вероятно, зря).
Если бы я до сих пор работал в Маркете и был в курсе что там в команде джавистов я бы мог подтвердить или опровергнуть описанное в статье. Из того, что я видел и где я работал — ничего подобного и близко не было.
nin-jin
Ну а меня в своё время уволили за неосторожное малозначительное сообщение в личном блоге, никак не афилированном ни со мной, ни с яндексом, который почти никто не читал. Ещё и полагающуюся при этом компенсацию платить не хотели. Собственно, в корпоративной вики так прямо и было написано, мол писать в своём блоге вы, конечно, можете что угодно, но имейте ввиду, что коллеги могут не захотеть после этого с вами работать. Мне вот и повезло, что со мной не захотел работать руководитель проекта.)
Нытьё про работоспособность java-приложения под виндой я тоже не разделяю, но у всех свои тараканы. И в любом тексте можно найти какой-нибудь изъян, что не делает этот текст ложным.
ABBAPOH
Ого, ничего себе. А можно подробности (в личку)?
Ну так там не один такой изъян — про монорепу фигня написана, про качество кода, про велосипеды, про легаси. То есть оно конечно в какой-то мере есть (покажите мне проект без легаси), но не это ужас-ужас достойный целой статьи.
С чем я могу согласиться — это переработки, но это как-то о-малое от всего описанного.
nin-jin
Я мало уже помню подробностей.
Не сказал бы что фигня. Какой смысл держать в монорепе не связанные друг с другом проекты? Тем более, что правильно приготовленная мультирепа ничем не хуже.
ABBAPOH
Смысл в монорепе в том что у вас есть легкий доступ к тем самым велосипедам. И да, «не связанные» проекты в том числе хотят иметь этот доступ. Нужна библиотечка из Утилей — подключили одной строкой в ya.make. Захотела ваша тулза из 10 строк ходить в YT — фигня вопрос, ну подумаешь вместо 10 секунд компилируется теперь 40 минут. Зато экономится время разработчика — не надо пилить свой локальный велосипед когда есть алгортим/функция/библиотека/велосипед в Аркадии. Например, поиск Маркета юзает плюс-минус тот же код, что и основной поиск.
Не, я не спорю, что при должном тулинге можно сделать это и на мультирепах, но проблема в том что и в случае монорепы и в случае мультирепы этот тулинг нужен (ни то ни другое не является серебрянной пулей и не работает из коробки) — в силу тех или иных причин Яндекс выбрал монорепу и связанный с ней тулинг. Утверждать, что монорепа — говно, «забыв» о необходимости (другого) тулинга для мультирепы — это писать фигню, потому что складывается впечатление что в Яндексе дурачки, а вот мультирепа все проблемы решит из коробки.
gecube
что монорепа, что мультирепа — оба подхода требует обмазывания соответствующими тулингами. Но в случае мультирепы ты еще можешь взять условный гитлаб, то. в случае монорепы даже Майкрософту пришлось написать адаптированную фс для гита, чтобы эффективно работать с большой кодовой базой
ABBAPOH
Да, гитхаб это клево и удобно, а как быть с переменованием функций, например? В Аркадии я могу взять и заменить Stroka на TString одним коммитом.
А вот взять товарищей из Qt, у них мультирепа. Вот я хочу переименовать функцию из QtCore которая используется в другом сабмодуле. Это надо добавить функцию-обертку, закоммитить, пойти в другой модуль, заюзать враппер там, закоммитить, пойти в QtCore и наконец переименовать функцию, избавившись от обертки, закоммитить. Не слишком ли много действий для такой простой задачи?
nin-jin
По отдельному коммиту в каждую фичеветку каждого проекта тогда уж.
А чтобы такой ерундой не заниматься такие вещи лучше оформлять в виде какого-нибудь codemod, который запускается автоматом после слияния.
Похоже они перестарались и зачем-то разрезали один проект на несколько реп, что ничего кроме проблем не даёт. На репы имеет смысл нарезать по зоне ответственности.
nin-jin
То есть по ссылке вы не ходили? Там как раз описывается система которая автоматически выкачивает зависимости по мере их использования. Как из npm так и из отдельных репозиториев. Был бы я Яндексом, то отмасштабировал бы её и на яву и цпп. Но я не яндекс.
Вы мне можете не рассказывать проблематику, я с ней прекрасно знаком. Вообще, забавная ситуация. Я уже давно не работаю в компаниях масштабов яндекса, но с тех пор решил в своих инструментах множество специфичных для этих масштабов проблем. А яндекс не то что решить их не смог толком, но даже не интересуется моими наработками.
Тулинг там довольно тривиальный: обнаружил зависимость от директории — выкачал в неё репозиторий.
ABBAPOH
Я пролистал ссылку, понял что ничего не понимаю в Джаваскрипте и закрыл — я сходу не увидел высокоуровнего описания, а вникать в портянки кода на ЖС у меня нет желания, извините, веб разработка — не моё.
Нет, я прекрасно знаю, что все эти проблемы решаемы в мультирепе, скажем, в 2 Гисе был свой набор скриптов для этого. Можно и деб-пакеты собирать из различных репозиториев и рулить зависимостями на этом уровне, тоже подход. По всякому можно, я и не утверждаю что монорепа лучше чем мультирепа, я утверждаю что безапелляционно заявлять что «Х — говно» это профанационный уровень, которым проникнута вся статья.
Именно так и работает селективный чекаут в ya make=)
nin-jin
Но это реально говно. Такой подход не масштабируется. Полирепу же легко масштабировать.
ToSHiC
Это очень спорное утверждение. Сразу хочу сказать, что я не фанат монорепы.
Я работал с полирепой Почты — то ещё развлечение, вся фигня заключалась в том, что твою библиотеку юзали разные проекты, но каждый — какую-то версию, на которой они зафиксировались. Обновить у всех свою библиотеку, когда ты делаешь там фичу или баг какой чинишь, было ооочень сложно.
Я довольно долго использовал парадигму дебиановских пакетов и бинарную зависимость. Что я могу сказать: бинарная зависимость в C++ — это боль. Отдельно доставляют циклические зависимости, если у программ есть плагины. Ещё раз отдельно, но уже по-другому, доставляют переезды на новые версии ОС, когда тебе надо пересобрать ВСЁ, даже какие-то старые коммон-библиотеки, которые уже года 3 как заморожены.
Я даже дружил библиотеки, собранные из монорепы, с бинарными сборками в дебиановские пакеты, и отлов багов с клэшингом символов — это прям особое «удовольствие».
Стоит отметить, что везде это был C/C++ код, со всеми его проблемами динамической или статической линковки. Но общие моменты, что надо уметь делать минорные релизы, которые не ломают API+ABI, думаю, будут применимы ко всем языкам. Это тяжело, и это форсит накапливать подобные несовместимые изменения в большие пачки и делать большие мажорные релизы, которые требуют много работы для внедрения, переписывания кода у использующих данный код проектов и т.д. А пока все медленно переползают — надо поддерживать 2, а то и 3 мажорных релиза. И да, сложность поиска кода действительно есть, найти, из чего именно был собран какой либо бинарник/пакет далеко не так тривиально, как может показаться. Есть ещё «вирусные» изменения, типа включения поддержки нового стандарта C++ — это тянет за собой включение сборки с этим же стандартом и у всех зависимых компонентов. На сколько я понимаю, у Java есть примерно такая же фигня с целевой версией JVM, и примерно такая же проблема у JS кода, подобным «вирусным» изменением может быть использование более новой версии питона при разработке какой либо библиотеки.
В противоположность этому монорепа требует вносить изменения плавно и итеративно, можно даже вносить изменения, ломающие API, но своим же коммитов исправлять все использования из чужого кода, главное — сохранять совместимость на уровне сетевого протокола и формата данных. Да, это требует наличия тестов у проектов. Да, это несколько усложняет разработку в бранчах (поэтому обычно монорепа соседствует с trunk-based разработкой), но позволяет делать такие изменения у популярных, с точки зрения количества использующих их проектов, библиотек. Важно отметить, что монорепа — это не столько большой SVN/Mercurial/git/whatever, сколько система сборки, система контроля зависимостей, тестирование, система CI/CD и т.д.
nin-jin
То есть проблема в фиксации версий, а не полирепе.
А тут соответственно проблема в попытке полагаться на бинарную совместимость, а не полирепе.
Не надо поддерживать устаревший код. Тогда переползать будут гораздо быстрее.
ToSHiC
А какие предложения есть? Как вообще искать все проекты, которые используют твою библиотеку, особенно если разработка идёт в фиче-бранчах?
А на какую зависимость надо полагаться? Если по исходникам, то как фиксировать?
Как синхронизировать разработку, если твою библиотеку использует 50 проектов?
Вы абстрактно хорошие вещи говорите, но как их воплотить в реальную жизнь? Можете рассказать, как вы это видите для компилируемых языков?
gecube
Какая разница — компилируемый ли язык или интерпретируемый? Та или иная форма "dll hell" и необходимости менеджить зависимости никуда не девается. Самое простое, конечно, статическая линковка и затаскивать внешние модули целиком (и собирать вместе с ними). Сильно сложнее, когда зависимости через артефакты. Но ничего нового Вы не сказали — так или иначе эта проблема характерна для любой разработки. Как со стороны потребителей готовых блоков (библиотек), так и со стороны разработчиков (которым приходится поддерживать несколько версий в параллель и давать определенные гарантии на интерфейс библиотеки).
Теоретически можно построить фашизм и заставить всех использовать только последние версии в рамках отдельно взятой организации, но это просто космическое количество человеко-часов, чтобы поддерживать весь код в актуальном состоянии (а то! Думали, что айти это дешево и просто на кнопочки клацать!)
Кстати, я плачу горючими слезами, но в python до сих пор есть "детские" проблемы с менеджментом пакетов.
nin-jin
Не надо вообще таким заниматься. Заботиться об обновлениях — задача потребителя вашего кода. Вы можете ему помочь, если не будете ломать апи, а слом апи сопровождать codemod-ом, ну или хотя бы внятным сообщением об ошибке, из которого понятно как починить.
Не фиксировать. Вы бы всё же прочитали ту статью. Хотя бы раздел про версионирование. Там JS специфики не много, а проблемы рассматриваются довольно типичные.
ToSHiC
Собственно, в комментарии habr.com/ru/post/456288/#comment_20290512 поднимались проблемы, на которые не было получено ответа.
мне говорят о том, что вы коммон библиотеки или клиенты для своего сервиса, которыми пользуются потребители, не делали. Им, потребителям, надо, чтобы работало, а не тестировать ваши изменения по 10 раз на дню.По сути вы предлагаете trunk-based разработку, но, в отличие от монорепы, автор библиотеки не обязан проверять, что тот самый виртуальный общий транк (то есть все текущие последние ревизии/версии всего, что есть в репозитории) собирается и проходит тесты.
Простите, но ваши фразы типа
А фраза говорит о том, что вы совершенно не поняли мои слова про ABI.
Если бы мне предложили работать с какой либо библиотекой в концепции «автор может делать много изменений, поддерживает только транк/мастер, но на ваш (то есть мой) сервис ему, в целом, наплевать» — то я бы поостерёгся ею пользоваться и пошёл искать альтернативы.
Почему же в реальной жизни все JS-еры фиксируют версии? Почему не собирают всё на самой последней версии? Почему существуют LTS версии библиотек и даже операционных систем? Ваша концепция (vintage — это же вы?) не выглядит какой-то уникальной, почему никто не живёт так, если она столь хороша?
nin-jin
Вовсе нет. В фичеветках, как обычно.
Конечно, для этого существует CI
Вы зачем 10 раз в день ломаете мастер? Не надо так. Настройте CI чтобы не давал вам пушить в мастер непротестированный код.
Не наплевать. Просто ваш сервис — это ваш сервис. А его библиотека — это его библиотека. Бегать по 100500 сервисам и делать в них изменения видя код в первый раз в жизни — это мало того, что контр продуктивно, так ещё и опасно. К тому же открывать автору любой библиотеки доступ к вообще всем репозиториям — ну такое себе.
Мы тут не в "пусть говорят", чтобы использовать апелляцию к толпе в качестве аргумента.
ToSHiC
Ваш, или для вот тех проектов? Если у вас полирепа, то откуда вы вообще про их CI узнаете? Они там, с другой стороны компании, и вообще у них Teamcity, а не Jenkins.
Непротестированный моими тестами, или тестами пользователей моей библиотеки?
Это называется «проверка жизнью». Удачные концепции распространяются между компаниями и коллективами разработчиков, неудачные — забываются. И почему вы пропустили ту часть абзаца, где было про LTS и про жизнь на самой новой версии из NPM вот прям сейчас?
wataru
Если CI единое для всех проектов, то это уже, по сути, монорепа и есть. То, что у каждого проекта свой репозиторий, а не папочка в монорепе — сути не меняет.
gecube
очень спорный аргумент.
в монорепе Вы в принципе не можете версионировать отдельные "папочки" — фича-ветки это несерьезно. Монорепа хороша, когда у Вас есть несколько взаимосвязанных продуктов, которые бегут по последней версии (какой-нибудь SaaS). Для коробочной разработки — монорепа может быть отдельной болью.
В случае большого количества независимых реп — у каждой из них версионирование свое. Это может быть болью, когда нужно собрать продукт из них в кучу, но действительно ничего не мешает сделать отдельную мета-репу и в ней прописать все зависимости (версии)
wataru
А как это раздельное версионирование работает с единым CI?
Antervis
Плюс у монорепы есть пара «вкусных» бонусов. Например, вы можете поправить библиотеку вместе с клиентским кодом.
gecube
А вне монорепы, конечно, я не могу это сделать? Или все-таки могу, но Вы имеете в виду, что не за одну итерацию? Так одна итерация — это такая же фикция, потому что пока я там в trunk based монорепы буду все места править и делать тесты зелеными… ну, вы поняли
Antervis
gecube
Это не "прекоммитные" проверки, которые должны на машине разраба отрабатывать быстро (иначе зачем они ещё нужны). А предмержевые (не могу придумать более удачного слова) проверки — на фичеветке поверх мастера. И тогда, да, они могут быть "долгими". Что более важно — может быть конвенция, что все коммиты из фичеветки при мерже в мастер должны быть схлопнуты (squash) и снабжены цельным, адекватным описанием.
Antervis
* предполагая что они вообще могут на этой машинке запуститься и отработать.
gecube
а где я говорю, что на машине разработчика тесты вообще должны гоняться? Простые проверки != юнит-тест != полный сет тестов. Ну, может на машинке разработчика максимум там линтер прогоняется. Или что там не очень дорого гонять.
Ну, и почему тогда Вы именно про предкоммитные проверки говорите? Прекоммит означает, что если что-то не так, то сразу все фейлится и в истории (гита, например) ничего не остается. Например, на прекомит правильно вешать проверку на наличие паролей в репо.
А в остальном — разработчик — какая разница — пускай коммитит мусор в удаленное репо (главное, что не в мастер) — мы все равно перед мержем заставим его убрать его :-/
Окей — у нас разный подход именно из-за того, что в нормальных компаниях нету Аркадии (и не будет).
Antervis
gecube
Извините, ни один из Ваших аргументов за монорепу… Не серьезен.
Полностью согласен с nin-jin ниже.
Где противоречие? Повторюсь, что для любого проекта, будь он хоть в "полирепе", все указанные сущности будут нужны
babylon
Учитывая иногородний ограниченный контингент, взявший в плотное кольцо компанию, рассчитывать на самостоятельность средненизовых подразделений не приходиться. Им бы день простоять, да ночь продержаться. И так до пенсии или до волшебного пендаля. Главное не отклоняться от генеральной линии по горизонтали. Пример с тем как вас мурыжили с $mol показателен. Какие велосипедисты такие и велосипеды. Это как в известном анекдоте.
Я считаю, что такие уникальные разработки как $mol надо поддерживать всесторонне. Тогда да можно говорить об опережающих тренды разработках. Пока Яндекс похвастать может тем что паркует react. Это может и хорошее лицо, но чужое
nin-jin
Не то чтобы мурыжили. Просто обмен опытом никому оказался на самом деле не нужен. А на публику-то надо показывать хорошее лицо.
Hay
Не просто потому что женщина, но потому что при этом еще и жертва.
syfim
Забавно, если бы не этот комментарий, мне бы и в голову не пришло, что автор — девушка. Вам только кажется, что все так же как и вы смотрят на автора и его пол) Если тексте явно не указывается пол автора, я даже знать не буду, мужчина или женщина это писала. Да и не хочу — мне на это плевать, как и многим)
HabrOHero
Сразу видно насколько внимательно и качественно вы потребляете информацию, если даже не замечаете того от чьего лица идёт повествование.
Newbilius
"Обращаете внимание на пол автора? Да вы сексист!"
"Не обращаете внимание пол автора? Вы ужасно невнимательны!"
Нда. Без шансов :))
HabrOHero
Шутки шутками, а представьте как он книги читает, не различая моментов когда повествование переходит от нейтрального, стёртого, нулевого к самому персонажу, ну а его пол наверняка определяет по имени, что приводит нас к мысли о том, а что делать если это Саша?
Ну и самое главное как можно прочуствовать тонкие моменты в повествовании связанные именно с полом? Будет странно видеть в тексте поста рассказ о том как с автором заигрывал начальник, а вы не знали что это девушка…
Newbilius
Ну если совсем серьёзно, то зависит от тематики текста. В техническом посте даже если автор использует гендерные окончания в отношении себя — они роли не играют, и могут легко выкинуться из памяти как несущественная информация. В повествовании, завязанном в первую очередь на взаимодействие конкретных персонажей — может быть крайне важно.
В этом конкретном тексте после начал данного треда мне буквально пришлось полезть в пост, чтобы уточнить пол автора. Потому что вне зависимости от пола автора монорепозиторий или Java чем-то принципиально иным не станут :)
syfim
Первое же предложение в тексте:
Не «я уволилась», а «я уволился». С чего мне вообще должна была прийти в голову мысль, что автор — девушка? Вторым словом в статье автор обозначает себя мужчиной, информация закрепляется, дальше уже просто смотрю на детали статьи
ne555
Почему я должен думать, что того автора 'разоблачили' и она 'плохая'?
Вы так публично заявлете об этом, но ни приложив ни единого доказательства.
Я вам поставил минус заслужили.
Я сейчас открыл того автора sashavoloh и у нее есть статьи и высокая карма и лайков за подобную статью (про маркет) не меньше чем в этой, мне кажется, что вы что-то нездоровое 'просите'
Hay
А вы и не сможете, у вас отключился мозг.
Отличная иллюстрация того, как происходит отключение мужского мозга, когда он видит что «бедную» женщину «угнетают».
Так явно и нагло игнорировать доказательства по ссылке на комментарий с 76 плюсами, где под ним люди накидали еще доказательств, ссылоки на её посты твиттер, архиватч, инфу с linkedin и главное на её настоящее отношение к работе и её токсичность к мужчинам, казалось бы бери, не хочу, изучай, докапывайся до правды…
Ну что Хабровчане. по прежнему будете говорить, что я безоснователен? Что все оценивали тамошнюю жертву с критическим мышлением? Что мужской мозг не отключается при виде бедняжки которую нужно пожалеть и вступиться за неё?
c_kotik
Да да. Вам бы тут сообществу про токсичность втирать, обвинив изначально в отключении мозга. Мира и процветания.
Hay
Человек выше на полном серьёзе считает что я не предоставил ни одного доказательства, в упор не видит ссылку, что это если не отключение мозга?
Получается вы обвиняете его в том что он сделал это умышлено? Как и люди поддержавшие его плюсом?
Не знаю как вы, а я считаю иначе, это нормальное поведение когда мужики бросаются сломя голову вступаться за слабый пол, даже не пытаясь вникнуть в ситуацию, человек может и не хотел клеветать на меня, но сами понимаете как это бывает.
c_kotik
Вопрос не в доказательствах, какой то там девушке и её разоблачении. Вопрос в том, как это все было преподнесено.
Да и опять же — там юля, тут ваня. единственная связь, на которую изначально в комментариях — просто напомнило ту публикацию. и все. никто не защищал и не оправдывал. но пригорело в итоге у вас. а у хабражителей блекаут мыслительных процессов (с ваших слов). и вы удивляетесь негативной реакции сообщества?
Hay
Вопрос в доказательствах, читайте внимательно:
ne555
Как это нужно было преподнести? Написал коротко, сжато, фейк, вот ссылка на доказательства.
Ниже указало почему важно не распространять этот пост. Вы вообще кстати в курсе, что тогда не хило так просела репутация хабра, на других ресурсов люди откровенно смеялись с того, как можно откровенно надуть здешнее сообщество, и остаться безнаказанной, показав всю пассивность этого самого сообщества.
На хабре есть много хороший статьей с разборами нынешней системы рейтинга, кармы, продвижения постов и общих с этим проблем, но одно дело когда это простые истории из жизни, другое дело когда пойдут вбросы и откровенная дезинформация, такие посты будет набирать огромное количество плюсов и никто этому не воспрепятствует, да и зачем? Положительный опыт уже есть, администрации всё равно, пользователям тоже.
Не проецируйте ваше подгорание на меня, я уже давно ничего не ожидаю от здешних людей, и не испытываю по этому поводу эмоций.
И опять таки вы не внимательны, я уже писал выше:
Как можно удивляться чему-то нормальному и привычному?
gluck59
эээ, что, простите? Вы уж определитесь, кто вокруг вас "плохой".