Ну и также надо понимать, что разработчик задействован обычно где-то на половине от всего жизненного пути коммерческого проекта и видит только маленькую часть его.
Разработчик видит продукт в том виде, в котором он дойдёт до пользователя (либо свою часть продукта), но глубина этого погружения несравнимо выше, чем у менеджеров, которые, в свою очередь "сознательно или нет дистанцируются от ИТ вопросов", так что не вижу проблем.
Так долгие прогулки и плавание - это супер-советы, на самом деле. Можно ещё советовать щадящую гимнастику типа пилатеса (в простонародье ЛФК). Чтобы быть в форме супер-нагрузки и не нужны, нужна регулярность.
Прошу прощения, тон ваших комментариев сильно перекликался с @nuclight, а уж из него так и прёт.
И далеко не все хотят тут работать. Просто потому что привыкли к другому. Не всем по душе все эти требования, этот консерватизм. Видимо, отсюда и упреки - мы тут молодые-креативные, на острие технологий, а вы там заскорузлые старперы, сидящие по уши в древнем легаси.
Не надо, пожалуйста, всех под одну гребёнку грести. Если человек в любой ситуации считает себя Д'Артаньяном, у него на всех вокруг упрёки найдутся. Адекватные специалисты уважают работу друг друга.
Ваша правда. Мне уже постепенно становится стыдно за написанное. С другой стороны, дедушка жаждет общения и тон этого общения задаёт он сам. Может, дедушка об нас развлекается и проводит время, как ему нравится)
RPM - это такой формат пакетов. В крайнем случае число оборотов в минуту.
Ага, а RPS - это Rounds per second, Revolutions per second или, может, Reactor Protective System? Представляете, мы живём в мире, где одинаковые аббревиатуры могут означать разные понятия, в зависимости от предметной области.
Запросы же считают как RPS.
Вы мне сейчас буквально пытаетесь доказать, что если мы в своих метриках всей компанией используем RPM, то мы не правы? Все 5 тысяч человек? Вы серьёзно?
Нет, это не так, и вменяемый технарь должен иметь логику, чтобы это понимать.
Вменяемый технарь должен понимать, что различные технологии предназначены для решения различных задач. В вашей же картине мира есть единственно верный подход - ваш. Странно, что у вас проблемы с оплатой вашего труда. Сможет ли вменяемый технарь найти тут корреляцию, а то может и причинно-следственную связь?
Выборка достаточная, чтоб видеть - у этих людей общий уровень ниже.
Ух, я прям заинтригован. Поделитесь, что ли, величиной своей выборки, что у вас она стремится к нормальному распределению? Тысячи? Миллионы?
например, вспомнить, сколько лет был убыточен Твиттер
Всё тот же вменяемый технарь, если он немного расширит свой кругозор, узнает, что в мире (в том числе РФ) множество компаний, которые на протяжении длительного времени работают себе в убыток. Тем не менее их капитализация, а следовательно и конечная стоимость, каким-то образом растёт. И даже сотрудники не сидят без ЗП. Загадочное явление для нашего технаря, если он не соблаговолит немного погрузиться в экономику.
Оная "данность" не есть нормальное положение вещей.
Ну если у вас нет плана как мы с вами прямо сейчас можем это изменить, то вы занимаетесь банальным брюзжанием. Смысла в таком упражнении для уважающего себя технаря ноль.
Синтаксическим сахаром удобства обертки и ничем более. Потому опирается она на те же самые средства ОС под капотом.
Простите, но другой мой собеседник хотя бы отдаёт себе отчёт, почему он не интересуется той или иной технологией и, соответственно, не стесняется задавать вопросы. Вы же просто Д'Артаньян и всезнайка, смысла с вами дискутировать вообще нет.
Иметь резервный сервер для быстрого переключения в случае проблем с основным и иметь "запасной" сервер который можно подключить если производительности не хватает - это две разные вещи.
Я рад, что всё-таки ошибся и банковская инфраструктура имеет запас прочности в виде дублирования узлов. Хотя мне непонятна концепция держать железо "про запас" - но, возможно это специфика, с которой я не сталкивался.
Go не тот язык, который что-то может дать для решения наших задач.
Ну а зачем тогда вы задаёте вопросы, типа "Сможете гарантировать что сломавшаяся корутина не потащит за собой весь процесс?". Вы уже сформировали свою картину мира и я не собираюсь вас переубеждать. Если вы хотите переубедить меня - у вас тоже не выйдет, увы) Есть умные книжечки, написанные куда более квалифицированными людьми, чем мы с вами. Мы сейчас в комментах не решим ультимативную правду на тему того, чей подход лучше. Вы мне всего лишь доказываете, что намеренно ограничиваете свой кругозор и почему-то считаете, что все должны поступить также. Нет, все так делать не будут) Вы со своим зоопарком разбирайтесь, как вы привыкли, а мы со своим будем работать, как считаем нужным. Просто не надо нас убеждать в том, что раз вы вручную городите инфраструктуру, которую из коробки может предложить современный язык - вы лучше нас. Задротнее, хардкорнее - это да. Эффективнее? Ну в рамках своей роли, с доступными вам инструментами, вы, наверное, эффективны. Значит ли это, что ваш подход применим для всех и вообще является единственно верным? Вряд ли)
Ну начнем с того, я лично не представляю себе "монолит" таких размеров
Вы тут путаете ожидания от реальности с реальностью. В мире, где хардкорные специалисты "просто хорошо пишут код" и не забивают голову такими модными терминами, как сohesion и сoupling (прошу прощения за англицизмы, но перевод этих терминов на русский - отдельная проблема) и прочими архитектурами, очень часто можно встретить настолько связный монолит, что ни одна его часть не сможет работать самостоятельно. Рад, что у вас не так, но это не значит, что везде - как у вас.
Запускать еще один инстанс на том же сервере?
Вы в одном предложении пишете про критический отказ модуля и следом задаёте такой вопрос. Уж где-где, а в банке я бы ожидал дублирования ключевых систем для быстрой замены и перераспределения нагрузки. У вас категорически не может вся инфраструктура работать на ОДНОМ сервере.
Не так радикально, но по сути - да. Хардкор, здоровый консерватизм и высокая степень ответственности.
Я ещё немного попробую пошатать ваш элитаризм и брошу, потому что спорить с вашей степенью ответственности нет смысла - она и правда высока. Но вы всё же пишете так, будто вы занимаетесь "настоящей" работой, а вокруг все дурью страдают. Это не так: все занимаются работой в соответствии со своими целями. Ваша цель: сделать правки, минимально задев существующие механизмы. Вы можете позволить себе обсасывать 10 строк кода в течении нескольких дней, повышая производительность алгоритма на 0,01мс. При этом вас не волнует читаемость кода: легаси не легаси, главное - работает. Это нормально, это ваша работа. Цель ваших коллег, перекладывателей джейоснов: выкатить большую фичу (зачастую в нескольких экземплярах) с минимальными ошибками за приемлемое для бизнеса время. Они могут себе позволить написать O(n2) вместо O(log n) до первого рефакторинга. И это тоже ОК, потому что у них TTM в приоритете, а оптимизация будет потом. Но этот рефакторинг не может стоить как вся предыдущая разработка, поэтому им важно, чтобы код оставался читаемым. Все эти ООП, DDD и ваши нелюбимые фреймворки нужны для того, чтобы пришёл другой специалист и за минимальное время понял, что происходит в коде. Это их работа. Это два разных мира с разными темпами разработки и разными требованиями. Но это не значит, что вы работаете в разных энтрепрайзах - вы делаете один продукт. И это также не значит, что ваша работа сильно ценнее. Могут они работать без вашего ядра - нет. Сможете вы работать без них? Отдать напрямую клиентам ваш API и пусть развлекаются - я бы на это посмотрел. Да даже нельзя сказать, что ваша работа сложнее: у вас просто разная сложность (как пространственная и алгоритмическая). Жаль, что вы к своему возрасту (а он, как я вижу по комментариям, у вас солидный) не научились ценить коллег, а напитались старческой желчью. Искренне надеюсь, что со мной такого не будет.
Я на всякий случай уточню, что никому микросервисы не навязываю и не считаю решением всех проблем. Как я написал выше - это был абстрактный ответ на абстрактное брюзжание. Микросервисы, как и любая технология, имеет свою область применения. По моему опыту - это чаще всего ответ на растущую нагрузку, которую не может держать текущая архитектура приложения. Например, пресловутый монолит. В один день к вам приходит понимание, что неплохо бы текущий монолит распараллелить (как минимум, поднять один инстанс) в ответ на невероятную популярность вашего продукта. Вы можете остаться жить с идентичными инстансами монолита (и это ОК), а можете подумать о том, что они жирны и их деплой - это боль, а хотелось бы уметь скейлить нагрузку на ходу, добавляя и убирая инстансы с минимальными трудозатратами. Тогда вы начинаете анализировать код и выдёргивать из него те модули, который действительно должны скейлиться, оставляя основную кодовую базу работать в одном-двух экземплярах. Выдернув первый модуль, вы встали на путь микросервисов) Ваш же пример хорош, но это пример параллельных вычислений. Это способ решить конкретную задачу и не влияет на архитектуру всего приложения. Ну, и не могу не заметить, неминуемо нарвавшись на гору вашего негодования, что есть целые языки, разработанные с оглядкой на параллельные вычисления, например, нелюбимый хардкорными специалистами, вроде вас, Go :) И один из главных вопросов на любом собеседовании на Go - чем реализация горутин выгодно отличаются от распараллеливания средствами ОС. Опять же, оговорюсь, что я ничего не пропагандирую, и для вас ваш подход наверняка удобнее, потому что позволяет вам контролировать каждый параллельный процесс, например.
Мне просто кривое употребление, как и кривая орфография, глаза режет.
Вы что-то выпендриваетесь на пустом месте. Можно считать как RPM, так и RPS - в зависимости от потребности.
И про эти проблемы микросервисов уже не раз были статьи на Хабре.
Найдите мне технологию, про проблемы которой не было бы написано на Хабре. Вам показать кучу статей про ваш любимый C и чем он плох?
Приходит человек, говорит, я восемь лет работал аналитиком, научился Питону.
А вы ему: моё хобби - экстраполировать. Сегодня пришёл ты, завтра ещё один, к концу года нам не хватит офисного пространства.
Я это к тому, что странных людей в нашей профессии, как и в любой другой, хватает. Но от хардкорного инженера ожидаешь понимания понятия "репрезентативная выборка" и вообще основ статистики.
Людей, которые не создают что-то полезное, а только ухудшают, в отрасли действительно много.
Если за таковых считать любого специалиста, который не мыслит также, как вы - да, безусловно.
приходится разгребать кому-то другому, более квалифицированному, но на меньшей зарплате.
Так решайте эту проблему. Вот ваш коллега (как по профилю, так и по образу мышления, видимо) @SpiderEkb говорит, что неплохо устроился и ни на что не жалуется. Может, спросите у него пару советов?
почему-то часто много платят за хайп
"почему-то" тут лишнее. Платят за хайп - это данность, в которой мы живём. Просто раньше вся индустрия целиком была хайпом, поэтому вы не жаловались, а сейчас она разделилась и хайп проходит мимо вас, потому вы злитесь.
Это вы, конечно, нашли к чему придраться, браво. То, что вы чаще смотрите на метрики в секунду, конечно, делает вас более хардкорным специалистом, ух.
зато хотят микросервисы с джейсонами. Хотя это просадит те самые RPS
Или позволит вам параллелить нагрузку и обеспечивать запас стабильности кратный тому, что у вас есть сейчас. Без конкретики рассуждать сложно, конечно, но если уж вы выбрали абстрактное брюзжание, получайте абстрактный ответ.
приходят новенькие питонисты, ничего не понимают в Си
Это какой-то изощрённый юмор?
да, мы - более хардкорные специалисты.
Ну, как говорится, "Напиши на майке, носи на работу". Вот бы все в индустрии научились уважать друг друга без токсичности и мерянья размерами ложек, которыми им приходится хлебать говно. Мне не тяжело согласиться, что у вас сложная работа, требующая большого количества низкоуровневых знаний. Почему вам тяжело признать, что ваши коллеги тоже делают что-то полезное, просто у вас разные требования и задачи? Вам, может, меньше платят? Или у вас другие проблемы в жизни, которые вы проецируете на индустрию?
Ну смотрите. Вот вы пишете, что переписали модули 2016 года. При этом вы же меня пытаетесь убедить в своей точке зрения, а значит я могу с определённой уверенностью предположить, что это самый древний пример, который вы смогли быстро вспомнить. Значит, для меня приведённый вами пример звучит так: "даже я не сталкивался с кодом, старше 2016 года". Факт один, а интерпретации разные. Далее: вы пишете, что работаете с ядром АБС - это действительно сфера, в которой ничего не менялось на протяжении десятилетий. Но раз вы работаете в Альфе, то процентов 70 ваших коллег как раз таки занимаются тем, что перекладывают пресловутые джейсоны. Притом делают это именно на новомодных фреймворках и микросервисах, а их код не живёт в продакшне нетронутый более 5 лет, ибо деньги деньгами, а новомодных механик для облапошивания удобства клиентов подобного рода бизнес генерирует в огромном количестве: покрывая это всё экспериментами, а по результатам иногда выкидывая тысячи строк кода, которые писались для проверки гипотезы. Так что, их энтерпрайс - это не ваш энтерпрайс? Вы считаете себя более хардкорным специалистом, так как работаете "в сердце" компании, а вокруг вас - суета и томление духа? Ну предлагаю подумать над тем, что ваши коллеги пишут код, гоняющий джейсоны при нагрузке в сотни тысяч RPM. И на их плечи ложится задача отфильтровать и провалидировать весь поток хаотичных телодвижений от пользователей так, чтобы он тоненькой струйкой дошёл до ваших корневых систем и не вызвал в них никаких взаимоисключающих действий.
Тиньковы, Озоны и прочий российский FAANG - это недостаточно энтерпрайзный энтерпарйз? Им уже 10 и более лет, и тем не менее, там успешно переписывают старый код.
Почему у вас кровавый энтерпрайз противопоставляется фреймворкам и обязательно ассоциируется с дремучим легаси? Это параллельные свойства, не зависящие друг от друга. Может быть и мини-студия на 3 человека с диким легаси и нерелевантным стеком, а может и энтерпрайз, сумевший переехать на микросервисы.
посокрушаться, что есть траблы и с разделителями, и с экранированием, да и кодировка внезапно разная бывает!
Ну то есть ты написал велосипед, который единожды отработал, но сломается при следующем вызове и считаешь, что запилил интеграцию? Сеньористо. Создаётся впечатление, что у вас в компании много подобных решений.
Но означает он по-прежнему: "Мы не знаем, что это такое. Если бы мы знали, что это такое, но мы не знаем, что это такое".
Разработчик видит продукт в том виде, в котором он дойдёт до пользователя (либо свою часть продукта), но глубина этого погружения несравнимо выше, чем у менеджеров, которые, в свою очередь "сознательно или нет дистанцируются от ИТ вопросов", так что не вижу проблем.
Так долгие прогулки и плавание - это супер-советы, на самом деле. Можно ещё советовать щадящую гимнастику типа пилатеса (в простонародье ЛФК).
Чтобы быть в форме супер-нагрузки и не нужны, нужна регулярность.
Прошу прощения, тон ваших комментариев сильно перекликался с @nuclight, а уж из него так и прёт.
Не надо, пожалуйста, всех под одну гребёнку грести. Если человек в любой ситуации считает себя Д'Артаньяном, у него на всех вокруг упрёки найдутся. Адекватные специалисты уважают работу друг друга.
Ваша правда. Мне уже постепенно становится стыдно за написанное. С другой стороны, дедушка жаждет общения и тон этого общения задаёт он сам.
Может, дедушка об нас развлекается и проводит время, как ему нравится)
Ага, а RPS - это Rounds per second, Revolutions per second или, может, Reactor Protective System?
Представляете, мы живём в мире, где одинаковые аббревиатуры могут означать разные понятия, в зависимости от предметной области.
Вы мне сейчас буквально пытаетесь доказать, что если мы в своих метриках всей компанией используем RPM, то мы не правы? Все 5 тысяч человек? Вы серьёзно?
Вменяемый технарь должен понимать, что различные технологии предназначены для решения различных задач. В вашей же картине мира есть единственно верный подход - ваш. Странно, что у вас проблемы с оплатой вашего труда. Сможет ли вменяемый технарь найти тут корреляцию, а то может и причинно-следственную связь?
Ух, я прям заинтригован. Поделитесь, что ли, величиной своей выборки, что у вас она стремится к нормальному распределению? Тысячи? Миллионы?
Всё тот же вменяемый технарь, если он немного расширит свой кругозор, узнает, что в мире (в том числе РФ) множество компаний, которые на протяжении длительного времени работают себе в убыток. Тем не менее их капитализация, а следовательно и конечная стоимость, каким-то образом растёт. И даже сотрудники не сидят без ЗП. Загадочное явление для нашего технаря, если он не соблаговолит немного погрузиться в экономику.
Ну если у вас нет плана как мы с вами прямо сейчас можем это изменить, то вы занимаетесь банальным брюзжанием. Смысла в таком упражнении для уважающего себя технаря ноль.
Закончились аргументы - назови оппонента безграмотным.
Простите, но другой мой собеседник хотя бы отдаёт себе отчёт, почему он не интересуется той или иной технологией и, соответственно, не стесняется задавать вопросы.
Вы же просто Д'Артаньян и всезнайка, смысла с вами дискутировать вообще нет.
Я рад, что всё-таки ошибся и банковская инфраструктура имеет запас прочности в виде дублирования узлов. Хотя мне непонятна концепция держать железо "про запас" - но, возможно это специфика, с которой я не сталкивался.
Ну а зачем тогда вы задаёте вопросы, типа "Сможете гарантировать что сломавшаяся корутина не потащит за собой весь процесс?". Вы уже сформировали свою картину мира и я не собираюсь вас переубеждать. Если вы хотите переубедить меня - у вас тоже не выйдет, увы) Есть умные книжечки, написанные куда более квалифицированными людьми, чем мы с вами. Мы сейчас в комментах не решим ультимативную правду на тему того, чей подход лучше.
Вы мне всего лишь доказываете, что намеренно ограничиваете свой кругозор и почему-то считаете, что все должны поступить также. Нет, все так делать не будут) Вы со своим зоопарком разбирайтесь, как вы привыкли, а мы со своим будем работать, как считаем нужным. Просто не надо нас убеждать в том, что раз вы вручную городите инфраструктуру, которую из коробки может предложить современный язык - вы лучше нас.
Задротнее, хардкорнее - это да. Эффективнее? Ну в рамках своей роли, с доступными вам инструментами, вы, наверное, эффективны. Значит ли это, что ваш подход применим для всех и вообще является единственно верным? Вряд ли)
Вы тут путаете ожидания от реальности с реальностью. В мире, где хардкорные специалисты "просто хорошо пишут код" и не забивают голову такими модными терминами, как сohesion и сoupling (прошу прощения за англицизмы, но перевод этих терминов на русский - отдельная проблема) и прочими архитектурами, очень часто можно встретить настолько связный монолит, что ни одна его часть не сможет работать самостоятельно. Рад, что у вас не так, но это не значит, что везде - как у вас.
Вы в одном предложении пишете про критический отказ модуля и следом задаёте такой вопрос. Уж где-где, а в банке я бы ожидал дублирования ключевых систем для быстрой замены и перераспределения нагрузки. У вас категорически не может вся инфраструктура работать на ОДНОМ сервере.
Почитайте, расширьте кругозор)
Я ещё немного попробую пошатать ваш элитаризм и брошу, потому что спорить с вашей степенью ответственности нет смысла - она и правда высока. Но вы всё же пишете так, будто вы занимаетесь "настоящей" работой, а вокруг все дурью страдают.
Это не так: все занимаются работой в соответствии со своими целями.
Ваша цель: сделать правки, минимально задев существующие механизмы. Вы можете позволить себе обсасывать 10 строк кода в течении нескольких дней, повышая производительность алгоритма на 0,01мс. При этом вас не волнует читаемость кода: легаси не легаси, главное - работает. Это нормально, это ваша работа.
Цель ваших коллег, перекладывателей джейоснов: выкатить большую фичу (зачастую в нескольких экземплярах) с минимальными ошибками за приемлемое для бизнеса время. Они могут себе позволить написать O(n2) вместо O(log n) до первого рефакторинга. И это тоже ОК, потому что у них TTM в приоритете, а оптимизация будет потом. Но этот рефакторинг не может стоить как вся предыдущая разработка, поэтому им важно, чтобы код оставался читаемым. Все эти ООП, DDD и ваши нелюбимые фреймворки нужны для того, чтобы пришёл другой специалист и за минимальное время понял, что происходит в коде. Это их работа.
Это два разных мира с разными темпами разработки и разными требованиями. Но это не значит, что вы работаете в разных энтрепрайзах - вы делаете один продукт. И это также не значит, что ваша работа сильно ценнее. Могут они работать без вашего ядра - нет. Сможете вы работать без них? Отдать напрямую клиентам ваш API и пусть развлекаются - я бы на это посмотрел.
Да даже нельзя сказать, что ваша работа сложнее: у вас просто разная сложность (как пространственная и алгоритмическая).
Жаль, что вы к своему возрасту (а он, как я вижу по комментариям, у вас солидный) не научились ценить коллег, а напитались старческой желчью. Искренне надеюсь, что со мной такого не будет.
Я на всякий случай уточню, что никому микросервисы не навязываю и не считаю решением всех проблем. Как я написал выше - это был абстрактный ответ на абстрактное брюзжание.
Микросервисы, как и любая технология, имеет свою область применения. По моему опыту - это чаще всего ответ на растущую нагрузку, которую не может держать текущая архитектура приложения. Например, пресловутый монолит. В один день к вам приходит понимание, что неплохо бы текущий монолит распараллелить (как минимум, поднять один инстанс) в ответ на невероятную популярность вашего продукта. Вы можете остаться жить с идентичными инстансами монолита (и это ОК), а можете подумать о том, что они жирны и их деплой - это боль, а хотелось бы уметь скейлить нагрузку на ходу, добавляя и убирая инстансы с минимальными трудозатратами. Тогда вы начинаете анализировать код и выдёргивать из него те модули, который действительно должны скейлиться, оставляя основную кодовую базу работать в одном-двух экземплярах. Выдернув первый модуль, вы встали на путь микросервисов)
Ваш же пример хорош, но это пример параллельных вычислений. Это способ решить конкретную задачу и не влияет на архитектуру всего приложения.
Ну, и не могу не заметить, неминуемо нарвавшись на гору вашего негодования, что есть целые языки, разработанные с оглядкой на параллельные вычисления, например, нелюбимый хардкорными специалистами, вроде вас, Go :) И один из главных вопросов на любом собеседовании на Go - чем реализация горутин выгодно отличаются от распараллеливания средствами ОС.
Опять же, оговорюсь, что я ничего не пропагандирую, и для вас ваш подход наверняка удобнее, потому что позволяет вам контролировать каждый параллельный процесс, например.
Вы что-то выпендриваетесь на пустом месте. Можно считать как RPM, так и RPS - в зависимости от потребности.
Найдите мне технологию, про проблемы которой не было бы написано на Хабре. Вам показать кучу статей про ваш любимый C и чем он плох?
А вы ему: моё хобби - экстраполировать. Сегодня пришёл ты, завтра ещё один, к концу года нам не хватит офисного пространства.
Я это к тому, что странных людей в нашей профессии, как и в любой другой, хватает. Но от хардкорного инженера ожидаешь понимания понятия "репрезентативная выборка" и вообще основ статистики.
Если за таковых считать любого специалиста, который не мыслит также, как вы - да, безусловно.
Так решайте эту проблему. Вот ваш коллега (как по профилю, так и по образу мышления, видимо) @SpiderEkb говорит, что неплохо устроился и ни на что не жалуется. Может, спросите у него пару советов?
"почему-то" тут лишнее. Платят за хайп - это данность, в которой мы живём. Просто раньше вся индустрия целиком была хайпом, поэтому вы не жаловались, а сейчас она разделилась и хайп проходит мимо вас, потому вы злитесь.
Странно, у вас тут пост буквально про выгорание. Вижу, что перевод, но не с пустого же места вы за такой труд взялись?
Это вы, конечно, нашли к чему придраться, браво. То, что вы чаще смотрите на метрики в секунду, конечно, делает вас более хардкорным специалистом, ух.
Или позволит вам параллелить нагрузку и обеспечивать запас стабильности кратный тому, что у вас есть сейчас. Без конкретики рассуждать сложно, конечно, но если уж вы выбрали абстрактное брюзжание, получайте абстрактный ответ.
Это какой-то изощрённый юмор?
Ну, как говорится, "Напиши на майке, носи на работу".
Вот бы все в индустрии научились уважать друг друга без токсичности и мерянья размерами ложек, которыми им приходится хлебать говно.
Мне не тяжело согласиться, что у вас сложная работа, требующая большого количества низкоуровневых знаний. Почему вам тяжело признать, что ваши коллеги тоже делают что-то полезное, просто у вас разные требования и задачи?
Вам, может, меньше платят? Или у вас другие проблемы в жизни, которые вы проецируете на индустрию?
Ну смотрите.
Вот вы пишете, что переписали модули 2016 года. При этом вы же меня пытаетесь убедить в своей точке зрения, а значит я могу с определённой уверенностью предположить, что это самый древний пример, который вы смогли быстро вспомнить. Значит, для меня приведённый вами пример звучит так: "даже я не сталкивался с кодом, старше 2016 года". Факт один, а интерпретации разные.
Далее: вы пишете, что работаете с ядром АБС - это действительно сфера, в которой ничего не менялось на протяжении десятилетий. Но раз вы работаете в Альфе, то процентов 70 ваших коллег как раз таки занимаются тем, что перекладывают пресловутые джейсоны. Притом делают это именно на новомодных фреймворках и микросервисах, а их код не живёт в продакшне нетронутый более 5 лет, ибо деньги деньгами, а новомодных механик для
облапошиванияудобства клиентов подобного рода бизнес генерирует в огромном количестве: покрывая это всё экспериментами, а по результатам иногда выкидывая тысячи строк кода, которые писались для проверки гипотезы.Так что, их энтерпрайс - это не ваш энтерпрайс? Вы считаете себя более хардкорным специалистом, так как работаете "в сердце" компании, а вокруг вас - суета и томление духа?
Ну предлагаю подумать над тем, что ваши коллеги пишут код, гоняющий джейсоны при нагрузке в сотни тысяч RPM. И на их плечи ложится задача отфильтровать и провалидировать весь поток хаотичных телодвижений от пользователей так, чтобы он тоненькой струйкой дошёл до ваших корневых систем и не вызвал в них никаких взаимоисключающих действий.
Тиньковы, Озоны и прочий российский FAANG - это недостаточно энтерпрайзный энтерпарйз? Им уже 10 и более лет, и тем не менее, там успешно переписывают старый код.
Почему у вас кровавый энтерпрайз противопоставляется фреймворкам и обязательно ассоциируется с дремучим легаси? Это параллельные свойства, не зависящие друг от друга.
Может быть и мини-студия на 3 человека с диким легаси и нерелевантным стеком, а может и энтерпрайз, сумевший переехать на микросервисы.
Циничный, но обезображенный эмоциональным интеллектом, коего мы, асоциальные задроты, напрочь лишены.
Принять-то, безусловно, может. А сколько может предложить от предыдущего оклада?
Ну то есть ты написал велосипед, который единожды отработал, но сломается при следующем вызове и считаешь, что запилил интеграцию? Сеньористо.
Создаётся впечатление, что у вас в компании много подобных решений.