Космические инструменты круты, они позволяют проникнуть в глубины мироздания и раскрывают тайны нашего прошлого и будущего.
Как жаль, что вместо по-настоящему полезных инструментов политиканы перенаправляют деньги в пилотируемую космонавтику, которая исчерпала себя как с научной, так и с концептуальной точки зрения десятки лет назад.
На деньги, потраченные на МКС, можно запустить десятки детекторов LISA, крутых космических телескопов и пробурить поверхность Европы.
Вместо познания Вселенной мы вбухиваем деньги в сомнительные исследования о возможности игры в тенис в невесомости.
Наука, в целом, развивается, но общество деградирует.
ООП явно не тянет на отдельную парадигму, это всего лишь, скажем так, частный случай Dinamic Dispatch, причём самый простой вариант - single dispatch.
ООП появилось во времена графических интерфейсов и хорошо подходит именно как API для общения с операционной системой.
Но для других задач, например, там где часто взаимодействуют несколько равноправных объектов, ООП подходит не очень хорошо, хотя бы потому, что нельзя выделить "главный" объект. Отсюда и берут ноги "контролеры", "менеджеры" и пр. Для этих целей нужен уже multiple dispatch (но его сложнее реализовать из-за недетерминированного выбора функции).
В общем, не надо переоценивать ООП. Иногда вижу, как пытаются натянуть сову на глобус, пытаясь объяснить как надо "правильно" использовать ООП, но факт в том, что ООП действительно не очень хорошо подходит для многих задач.
А вот "pattern matching" и логическое программирование - действительно отдельные парадигмы, для них и матмодели имеются, так что утверждение, что других парадигм "нет и не будет" очевидно абсурдно
Нет ничего страшного если название комитета прочитается с акцентом. В рекомендация по акцесабилити нет такого, чтобы все фрагменты помечать языком. Есть гораздо более серьёзные проблемы
Зачем менять пакеты, если джава обратно совместима? Есть, конечно, исключения, но у других языков проблем с совместимостью гораздо больше.
Спринг это такая штука, которая позволяет долго сидеть, читать доку и прочее чтобы разобраться, почему она сломалась в этом месте, вместо того, чтобы самому писать код и иметь понимание, что он делает, а не трясти волшебную черную коробку
Я вас уверяю, что без знания "матана" вы ни один проект нормально не напишите, это касается не только джавы, но и других инструментов: средств сборки, баз данных, докеров и кубернетисов.
ИТ-инженеру надо знать много, не меньше чем доктору или микробиологу. Видео с конференций это конечно хорошо, но всегда надо хотя бы поверхностно изучить документацию того, с чем часто работаешь.
самому писать код и иметь понимание
Ваш код понятен только вам, спринг понятен всем грамотным разработчикам.
О чём вы, какие конфиги. Я xml уже лет 5 как не видел. Спринг это такая штука, которая позволяет не заниматься фигнёй в сотый раз изобретая велосипед (типа того что в статье описано), а скучно заниматься бизнес-логикой.
Недавно обновлял джаву в нескольких проектах, поменял цифру с 11 до 17 - вот и все дела, 2 часа достаточно. То что там гошники с питонщикамис версиями страдают - так это они сами свой крест выбрали.
Вряд ли среди джавистов намного больше высококвалифицированных, свободных, и находящихся в активном поиске разработчиков, чем в go.
Именно так. Хотя бы потому, что джава существует дольше и у разработчиков больше опыт.
Повторюсь, эффективность зависит не только от квалификации, но и от развитых инструментов и библиотек, книг, в конце концов.
Я конечно понимаю, что не вы выбирали Go, а эффективные менеджеры, просто дико видеть как простые системные задачи, вроде настройки кешей, превращается в настоящий квест
В golang тоже вполне себе неплохие средства профайлинга имеются, ими и пользуемся про поиске мест для потимизаций. https://go.dev/blog/pprof
Это то что вы привели по ссылке вы называете "неплохими средствами профайлинга", то что тогда плохое средство??
Хороший инструмент для профайлинга должен выглядеть хотя бы вот так. Для джавы подобных инструментов я знаю как минимум 6. Сколько подобных инструментов есть для GO?
Как может десериализация данных занимать целую секунду? Там мегабайты данных что-ли? Зачем вообще что-то десериализировать? Вы же байты кешируете, не так ли?
С чем связан выбор го для бакэнда? В той же Java вопросы перформанса решаются достаточно просто, есть разные библиотеки для кеширования, развитые средства профайлинга и мониторинга, есть куча разработчиков которые понимают как делать быстро и надёжно. Если бы я стал что-то делать на го, то я бы никогда не достиг бы такой производительности как на Java или C++, просто потому что язык малоизвестный и непонятно как его "готовить".
это чаще всего задержки in-memory очередей где-то в системе, те самые "флапы". Их норм ретраить. Происходят либо из-за случайностей (не повезло и на данном поде параллельно выполнялся очень тяжелый запрос, съевший CPU), либо когда одному поду плохонько
С какой это стати корректность работы сервиса должна зависеть от случайностей? Для подов настраиваются ресурсы, а сервисы тестируют на производительность, чтобы такого не было. Да и какой смысл повторять, если можно просто подождать подольше ?? Повторы только увеличат задержки, но никак не уменьшат.
даже если такое правило принять, то его нереально выполнять: для этого нужно чтобы каждый сервис или СУБД при получении сетевой ошибки от зависимостей, наружу тоже выдавал сетевую ошибку (например, тайм-аутил или разрывал коннект)
С чего это вы так решили? Любая невосстановимая ошибка выдаёт 500. Да и зачем серверу имитировать сетевую ошибку. Это было бы странно, не находите?
А если не выдать сетевую ошибку - не будет ретрая. Но так код не пишут обычно
Именно так его и пишут
тайм-ауты в exponential backoff не увеличиваются, растут лишь паузы между попытками.
Паузы увеличивают общее время недоступности сервера, а пока мы не определимся, доступен сервис или нет, мы не можем дать ответ последующим сервисам
на 1 под мог только что выехать канареечный релиз, который кидает 500 на 1% специфичных запросов. Хорошо бы его отретраить в другой под.
В чём тогда его канареечность, если запрос всё равно падает на другой инстанс?
Я немного не понимаю, почему нельзя, в случае если сервер не справляется с нагрузкой, просто выдавать отдельный код ошибки, а клиент, в случае её получения, просто не будет делать повторы.
Это, впрочем, касается любой серверной ошибки (aka 500 - Internal Server Error). Если сервисы идемпотенты, то одинаковые данные приведут к одинаковым ошибкам. Если этот так, то зачем вообще повторять? Я такое видел, когда пытаются скомпенсировать багливость сервиса с помощью повторов, сродни заметанию пыли под ковёр. Надо ли говорить, что обычно это только усугубляет ситуацию, ибо нахождение ошибок становится более сложной задачей?
Ретраи нужнытолько для сетевых ошибок и больше ни для чего другого.
Кроме того, вызывает вызывает сомнение в пользе увеличивающих таймаутов в небатчевых сервисах. Если клиентский сервис может отвалиться по таймауту, то экспотенциальные повторы только увеличат вероятность таймаута
Ну в Windows всё оборудование работает более-менее, поэтому всё рассуждения из разряда: кабель не тот, память не та, карточка неправильная выглядят вообще неубедительно.
Но у каджита включены экспериментальные фичи
Интересно как мне это нагуглить, если у меня мыша не работает?
⸘⸘⸘что у вас за DE такое маргинальное, что там даже этого нет‽‽‽
Насколько помню, изменение скорости не поддерживается на уровне xorg - только ускорение.
Тут могу ошибаться, но точно помню как тяжело это было настраивать. Для колёсика надо было imwheel ставить и настраивать, ибо именно в хромиуме не так работало. Для скорости мыши пришлось TransformationMatrix тюнить
У вас там, часом, не Cinnamon, кстати?
Угадали
Впрочем, ее-то сломал не арч, отнюдь, она сломана в самих кедах была.
К сожалению далеко не всё так радужно. Являюсь завсегдаем arch-wiki, постояно приходится что-то фиксить.
Либо вам очень повезло, либо вы как-то не особо активно его используете или непритязательны
Из примеров:
частота в 30г в 4K LG мониторе через USB, в Windows - 60
кривая поддержка низкоэнегетичных блютуз мышек, приходится подключаться из консоли наугад, ибо не отображается название устройства.
периодические (раз в пару дней) зависания интерфейса, полечилось апргрейдом памяти. Но в Windows такой проблемы не возникало
невозможность легко настроить скорость мышки и скорость колёсика. Лечится скриптами и конфиг файлами, но это жесть.
после настройки размеров шрифтов - кривой интерфейс в джава приложениях, включая Intelij Idea
особенность арча: постоянно после апдейта что-то отваливается. Из последнего: сломалась смена обоев рабочего стола (лечится даунгрейдом python-pillow).
Программисты во всём мире используют встроенный HTTP в IntelijIdea и довольны как слоны. Зачем нужен этот дикий ужас с баш-скриптами - одному автору известно.
Видимо, само существование Postman-а заставляет кого-то не пользоваться нормальными инструментами и городить огород.
Автор не упомянул другую проблему, актуальную во многих странах - это агрессивный феминизм.
Ситуация когда от мужчин требуется чуть ли не заверенное у нотариуса согласие на секс, как бы не способствует развитию отношений. На работе познакомиться? Кошмар! Ни в коем случае!
А после женитьбы всегда есть шанс попасть на бабло, если жена решит развесить и у неё окажутся грамотные юристы, которые заставят её обеспечивать на "должном" уровне.
Своих детей потом не увидишь, ибо она заявила про домашнее насилие, а доброе государство приняло меры чтобы ты к ней не приближался.
Впрочем я не считаю, что снижение рождаемости это плохо. По-моему, объективно чем меньше людей - тем лучше.
В распределенных системах это обычно внешние распределенные кеши, типа Redis или Hazelcast
Ссылку на статистику, плз. Распределённые обычно используются, если памяти на одном сервере не хватает. Для всего остального они мало полезны.
Проблема с балансировщиком
На клиентской стороне сделать балансировщик - религия не позволяет?
Скорее всего за это время уже запущенные контейнеры не смогут обработать запросы, начнут отказывать и выдавать ошибки
ээээ .... а готовность приверить до регистрации инстанса ваша инфраструктура не позволяет? В кубернетисе это как бы из коробки
Но в долгосрочной перспективе, естественно, мы переписываем микросервис так, чтобы он сам потреблял меньше ресурсов
Ну наконец-то! Хоть что-то вы делаете разумное.
При использовании событийного подхода вся интеграция построена при помощи маршрутизатора, когда нет прямых интеграций между сервисами, благодаря чему достигается слабая связность между ними. Если один из сервисов не доступен, вероятность того, что остальные выйдут из строя вслед за ним, снижается
Ничего не снижается. Есть такая штука, теория надёжности называется. Чем больше компонентов - тем менее надёжна система. Вы переносите с больной головы на здоровую подменяете одну точку отказа 2-мя точками отказа.
RabbitMQ или Kafka. В целом, эти каналы коммуникации by design более отказоустойчивые, чем REST, использующий HTTP
С чего это вдруг? Вообще-то они используют тот же самый TCP.
Там, где важная изоляция и надежность можно использовать SQL решения, там, где требуется горизонтальное масштабирование — NoSQL базы данных.
Так значит, SQL базы не обеспечивают горизонтального масштабирование, а NoSQL - надёжности? Ну надо же! Век живи - век учись!
Вот как раз из предложения, что у нас "особый проект", "очень большие данные, аж 100 гигов", "невероятные требования по быстродействию" и берут ноги самые идиотские и кривые архитектуры и решения.
При чём тут библиотеки? В микросервисах не используются библиотеки?
При том, что они написаны на разных языках и прекрасно уживаются, что сводит на нет ваш нелепый аргумент, будто монолит ограничивает технологии и языки.
Тогда всё ясно. Если разработчику комфортно работать 1 час в неделю, то значит это так правильно, и нечего возражать.
Мне вообще кажется, что качество кода обратно пропорционально числу написанных строчек.
Ведь "правильный монолит" совершенно точно и при любых раскладах будет лучше и кошерней "неправильных микросервисов"
Нет, вы просто не понимаете преимуществ и недостатков обоих подходов и находите сложности там где их никогда не было. Особенно доставляет утверждение что микросервисы якобы быстрее.
Может нам и от СУБД отказаться, от всех видов распределённых кешей тогда? :) Там тоже сетевое взаимодействие и сериализация/десериализация.
Конечно, встраиваемые БД потенциально быстрее. Более того, как раз в микросервисах встраиваемые БД особо полезны. Распределённые кэши - это настолько специфичная штука, что она вам вряд ли пригодится. Если вы их используете, то должны всегда отдавать себе отчёт - зачем.
Вообще, претензия на скорость сетевого взаимодействия в отношении микросервисов самая незначительная, но удивительно часто звучит от ярых адептов монолитов
Это потому что они сталкивались с этой проблемой, а вы ещё нет.
А ну да, точно. Какой весёлый монолит получается :) То-то разработчики C++ обрадуются перспективе уживаться с Rust-ом, Go, JS и Kotlin/Java в одном проекте и одном адресном пространстве. Просто мечта!
Странный вы какой-то. То вам в кровь из носа нужна гетерогенность, то жалуетесь на неё. Вы не поверите, но большинство программ использует кучу библиотек которые прекрасно уживаются в одном адресном пространстве. Представляете? Чудеса!
Ну и привычный уютный проект, какой мидл откажется выйти за рамки комфорта.
Зачем вообще из него выходить? Если архитектура правильная, спроектирована профессионалами, то разработчику (а также тестеру и админу) действительно очень комфортно. В этом её и ценность. А производительность идёт бонусом
Монолит всех подгоняет под одну гребёнку.
Кого он что подгоняет? Вы о чём ? ) Это такой троллинг чтоли??? Прям как из фильма идиократия получается: "нам надо пить воду с электролитами. Зачем? Потому что там электролиты! "
Космические инструменты круты, они позволяют проникнуть в глубины мироздания и раскрывают тайны нашего прошлого и будущего.
Как жаль, что вместо по-настоящему полезных инструментов политиканы перенаправляют деньги в пилотируемую космонавтику, которая исчерпала себя как с научной, так и с концептуальной точки зрения десятки лет назад.
На деньги, потраченные на МКС, можно запустить десятки детекторов LISA, крутых космических телескопов и пробурить поверхность Европы.
Вместо познания Вселенной мы вбухиваем деньги в сомнительные исследования о возможности игры в тенис в невесомости.
Наука, в целом, развивается, но общество деградирует.
ООП явно не тянет на отдельную парадигму, это всего лишь, скажем так, частный случай Dinamic Dispatch, причём самый простой вариант - single dispatch.
ООП появилось во времена графических интерфейсов и хорошо подходит именно как API для общения с операционной системой.
Но для других задач, например, там где часто взаимодействуют несколько равноправных объектов, ООП подходит не очень хорошо, хотя бы потому, что нельзя выделить "главный" объект. Отсюда и берут ноги "контролеры", "менеджеры" и пр. Для этих целей нужен уже multiple dispatch (но его сложнее реализовать из-за недетерминированного выбора функции).
В общем, не надо переоценивать ООП. Иногда вижу, как пытаются натянуть сову на глобус, пытаясь объяснить как надо "правильно" использовать ООП, но факт в том, что ООП действительно не очень хорошо подходит для многих задач.
А вот "pattern matching" и логическое программирование - действительно отдельные парадигмы, для них и матмодели имеются, так что утверждение, что других парадигм "нет и не будет" очевидно абсурдно
Никак не могу избавиться от ощущения, что где-то я уже видел эту бизнес-модель ...
Коммунизм какой-то.
У нас в Австралии 100мбит интернет в самом центре города стоит 48 EUR.
Никакой оптики разумеется, приземляется через VDSL. Моя телефонная линия поддерживает максимум 130 мбит.
До ковида и этого могло не быть - кругом был сплошной ADSL.
Ну и соответственно, старлинк здесь стоит 84 EUR в месяц
Нет ничего страшного если название комитета прочитается с акцентом. В рекомендация по акцесабилити нет такого, чтобы все фрагменты помечать языком. Есть гораздо более серьёзные проблемы
Зачем менять пакеты, если джава обратно совместима? Есть, конечно, исключения, но у других языков проблем с совместимостью гораздо больше.
Я вас уверяю, что без знания "матана" вы ни один проект нормально не напишите, это касается не только джавы, но и других инструментов: средств сборки, баз данных, докеров и кубернетисов.
ИТ-инженеру надо знать много, не меньше чем доктору или микробиологу. Видео с конференций это конечно хорошо, но всегда надо хотя бы поверхностно изучить документацию того, с чем часто работаешь.
Ваш код понятен только вам, спринг понятен всем грамотным разработчикам.
О чём вы, какие конфиги. Я xml уже лет 5 как не видел. Спринг это такая штука, которая позволяет не заниматься фигнёй в сотый раз изобретая велосипед (типа того что в статье описано), а скучно заниматься бизнес-логикой.
Недавно обновлял джаву в нескольких проектах, поменял цифру с 11 до 17 - вот и все дела, 2 часа достаточно. То что там гошники с питонщикамис версиями страдают - так это они сами свой крест выбрали.
Именно так. Хотя бы потому, что джава существует дольше и у разработчиков больше опыт.
Повторюсь, эффективность зависит не только от квалификации, но и от развитых инструментов и библиотек, книг, в конце концов.
Я конечно понимаю, что не вы выбирали Go, а эффективные менеджеры, просто дико видеть как простые системные задачи, вроде настройки кешей, превращается в настоящий квест
Это то что вы привели по ссылке вы называете "неплохими средствами профайлинга", то что тогда плохое средство??
Хороший инструмент для профайлинга должен выглядеть хотя бы вот так.
Для джавы подобных инструментов я знаю как минимум 6. Сколько подобных инструментов есть для GO?
Как может десериализация данных занимать целую секунду? Там мегабайты данных что-ли?
Зачем вообще что-то десериализировать? Вы же байты кешируете, не так ли?
С чем связан выбор го для бакэнда? В той же Java вопросы перформанса решаются достаточно просто, есть разные библиотеки для кеширования, развитые средства профайлинга и мониторинга, есть куча разработчиков которые понимают как делать быстро и надёжно. Если бы я стал что-то делать на го, то я бы никогда не достиг бы такой производительности как на Java или C++, просто потому что язык малоизвестный и непонятно как его "готовить".
Пытался найти в этом списке хоть что-то, чего нет в IntelijIdea и .... не нашёл ...
И это вы называете килер фичами?
На практике, мне сложно представить джависта или андроидщика, который пишет в VSСode.
Поэтому к статистике - бооооольшииииииие вопросы. Я уж молчу про то, что в сумме получается гораздо больше 100%
С какой это стати корректность работы сервиса должна зависеть от случайностей? Для подов настраиваются ресурсы, а сервисы тестируют на производительность, чтобы такого не было. Да и какой смысл повторять, если можно просто подождать подольше ?? Повторы только увеличат задержки, но никак не уменьшат.
С чего это вы так решили? Любая невосстановимая ошибка выдаёт 500. Да и зачем серверу имитировать сетевую ошибку. Это было бы странно, не находите?
Именно так его и пишут
Паузы увеличивают общее время недоступности сервера, а пока мы не определимся, доступен сервис или нет, мы не можем дать ответ последующим сервисам
В чём тогда его канареечность, если запрос всё равно падает на другой инстанс?
Ну дык верно, здесь нам не надо повторять - это же всё равно ничего не изменит. Надо сервис фиксить, а не повторами заниматься.
Я немного не понимаю, почему нельзя, в случае если сервер не справляется с нагрузкой, просто выдавать отдельный код ошибки, а клиент, в случае её получения, просто не будет делать повторы.
Это, впрочем, касается любой серверной ошибки (aka 500 - Internal Server Error). Если сервисы идемпотенты, то одинаковые данные приведут к одинаковым ошибкам. Если этот так, то зачем вообще повторять? Я такое видел, когда пытаются скомпенсировать багливость сервиса с помощью повторов, сродни заметанию пыли под ковёр. Надо ли говорить, что обычно это только усугубляет ситуацию, ибо нахождение ошибок становится более сложной задачей?
Ретраи нужны только для сетевых ошибок и больше ни для чего другого.
Кроме того, вызывает вызывает сомнение в пользе увеличивающих таймаутов в небатчевых сервисах. Если клиентский сервис может отвалиться по таймауту, то экспотенциальные повторы только увеличат вероятность таймаута
Ну в Windows всё оборудование работает более-менее, поэтому всё рассуждения из разряда: кабель не тот, память не та, карточка неправильная выглядят вообще неубедительно.
Интересно как мне это нагуглить, если у меня мыша не работает?
Насколько помню, изменение скорости не поддерживается на уровне xorg - только ускорение.
Тут могу ошибаться, но точно помню как тяжело это было настраивать. Для колёсика надо было imwheel ставить и настраивать, ибо именно в хромиуме не так работало. Для скорости мыши пришлось TransformationMatrix тюнить
Угадали
Ну в кедах, я думаю, до сих пор плазма падает
К сожалению далеко не всё так радужно. Являюсь завсегдаем arch-wiki, постояно приходится что-то фиксить.
Либо вам очень повезло, либо вы как-то не особо активно его используете или непритязательны
Из примеров:
частота в 30г в 4K LG мониторе через USB, в Windows - 60
кривая поддержка низкоэнегетичных блютуз мышек, приходится подключаться из консоли наугад, ибо не отображается название устройства.
периодические (раз в пару дней) зависания интерфейса, полечилось апргрейдом памяти. Но в Windows такой проблемы не возникало
невозможность легко настроить скорость мышки и скорость колёсика. Лечится скриптами и конфиг файлами, но это жесть.
после настройки размеров шрифтов - кривой интерфейс в джава приложениях, включая Intelij Idea
особенность арча: постоянно после апдейта что-то отваливается. Из последнего: сломалась смена обоев рабочего стола (лечится даунгрейдом python-pillow).
Программисты во всём мире используют встроенный HTTP в IntelijIdea и довольны как слоны. Зачем нужен этот дикий ужас с баш-скриптами - одному автору известно.
Видимо, само существование Postman-а заставляет кого-то не пользоваться нормальными инструментами и городить огород.
Автор не упомянул другую проблему, актуальную во многих странах - это агрессивный феминизм.
Ситуация когда от мужчин требуется чуть ли не заверенное у нотариуса согласие на секс, как бы не способствует развитию отношений. На работе познакомиться? Кошмар! Ни в коем случае!
А после женитьбы всегда есть шанс попасть на бабло, если жена решит развесить и у неё окажутся грамотные юристы, которые заставят её обеспечивать на "должном" уровне.
Своих детей потом не увидишь, ибо она заявила про домашнее насилие, а доброе государство приняло меры чтобы ты к ней не приближался.
Впрочем я не считаю, что снижение рождаемости это плохо. По-моему, объективно чем меньше людей - тем лучше.
Ссылку на статистику, плз. Распределённые обычно используются, если памяти на одном сервере не хватает. Для всего остального они мало полезны.
На клиентской стороне сделать балансировщик - религия не позволяет?
ээээ .... а готовность приверить до регистрации инстанса ваша инфраструктура не позволяет? В кубернетисе это как бы из коробки
Ну наконец-то! Хоть что-то вы делаете разумное.
Ничего не снижается. Есть такая штука, теория надёжности называется. Чем больше компонентов - тем менее надёжна система. Вы
переносите с больной головы на здоровуюподменяете одну точку отказа 2-мя точками отказа.С чего это вдруг? Вообще-то они используют тот же самый TCP.
Так значит, SQL базы не обеспечивают горизонтального масштабирование, а NoSQL - надёжности? Ну надо же! Век живи - век учись!
Вот как раз из предложения, что у нас "особый проект", "очень большие данные, аж 100 гигов", "невероятные требования по быстродействию" и берут ноги самые идиотские и кривые архитектуры и решения.
При том, что они написаны на разных языках и прекрасно уживаются, что сводит на нет ваш нелепый аргумент, будто монолит ограничивает технологии и языки.
Мне вообще кажется, что качество кода обратно пропорционально числу написанных строчек.
Нет, вы просто не понимаете преимуществ и недостатков обоих подходов и находите сложности там где их никогда не было. Особенно доставляет утверждение что микросервисы якобы быстрее.
Конечно, встраиваемые БД потенциально быстрее.
Более того, как раз в микросервисах встраиваемые БД особо полезны.
Распределённые кэши - это настолько специфичная штука, что она вам вряд ли пригодится. Если вы их используете, то должны всегда отдавать себе отчёт - зачем.
Это потому что они сталкивались с этой проблемой, а вы ещё нет.
Странный вы какой-то. То вам в кровь из носа нужна гетерогенность, то жалуетесь на неё. Вы не поверите, но большинство программ использует кучу библиотек которые прекрасно уживаются в одном адресном пространстве. Представляете? Чудеса!
Зачем вообще из него выходить? Если архитектура правильная, спроектирована профессионалами, то разработчику (а также тестеру и админу) действительно очень комфортно. В этом её и ценность. А производительность идёт бонусом
Кого он что подгоняет? Вы о чём ? ) Это такой троллинг чтоли??? Прям как из фильма идиократия получается: "нам надо пить воду с электролитами. Зачем? Потому что там электролиты! "