Когда-то я тоже так думал, а потом жизнь столкнула с сеньор разработчиком, который оказался в принципе неспособным написать toString() для древовидной структуры данных в реальном проекте.
С тех пор я всегда проверяю кандидатов на понимание рекурсии.
Почему же — только те, кто не имеет достаточно знаний и опыта, чтобы обойтись без спринга) Так-то, конечно, может быть множество причин сидеть на спринге.
Оставшиеся профессионалы? Сейчас софт в одиночку никто не пишет. «Поддерживаемость» кода в гораздо большей степени зависит от квалификации программистов и качества процессов разработки, чем от использования стандартных фреймворков.
Имхо, всё упирется в квалификацию программистов. Множество компаний при разработке ПО, особенно на заказ, предпочитает концепцию «дешево и сердито». Когда без знания HTTP пишут спринговые контроллеры, без знания яваскрипта — JSF/Vaadin, без знания SQL — Hibernate. И без умения проектировать серверный софт для продакшна берут готовый фреймворк и настраивают его через XML.
Конечно же, если нужно сделать что-то быстро, большой старый фреймворк позволит в кратчайшие сроки сделать нечто приемлемо работающее. НО — в нагрузку к 5% нужного функционала мы получаем 95% функционала ненужного, который замедляет приложение, добавляет дыры в безопасности и ограничивает свободу маневра. Про маленькие новые фреймворки хорошо написано вот тут.
Профессионалу намного удобнее взять набор маленьких, качественных библиотек и самому собрать из них приложение.
Для собственных приложений в приватных сетях это решается через service discovery. Для публичных сетей ставится прокси, который слушает публичный порт и перенаправляет запрос на нужный экземпляр, слушающий на произвольном порту.
Разделение сети как раз не проблема, 99% софта под линукс позволяет настраивать используемые порты. Проблема — это инсталляционные пакеты, которые крайне сложно установить без прав рута. Все норовят писать в /etc, прописывать себя в сервисы и разваливаться при попытке установить как-то иначе.
Лично я всегда деплою контейнеры с --net=host и никогда об этом не жалел.
По быстродействию хуже, но совсем ненамного — на один цикл и немного арифметики указателей.
Стандартная хешмапа для такого маленького набора строк ни разу не факт, что быстрее — вычисление хеша дороже, чем сравнение строк. Еще memory locality — хешмапа в плюсах построена на односвязных списках или с открытой адресацией?
В данном случае лучше вынести все строковые константы на сравнение в отдельный массив и итерироваться по нему.
Но универсальных решений все равно нет — вышеприведенный пример с большим if-ом, к примеру, имеет максимальное быстродействие, возвращая 4 сразу, как только найдет нужную строчку.
Я учился в 90х, далеко в тундре в среднеобразовательной школе. У нас был турбо паскаль и:
— массивы и односвязные списки
— сортировка пузырьком и вставками
— двоичный поиск
— деревья
С тех пор я всегда проверяю кандидатов на понимание рекурсии.
Конечно же, если нужно сделать что-то быстро, большой старый фреймворк позволит в кратчайшие сроки сделать нечто приемлемо работающее. НО — в нагрузку к 5% нужного функционала мы получаем 95% функционала ненужного, который замедляет приложение, добавляет дыры в безопасности и ограничивает свободу маневра. Про маленькие новые фреймворки хорошо написано вот тут.
Профессионалу намного удобнее взять набор маленьких, качественных библиотек и самому собрать из них приложение.
Лично я всегда деплою контейнеры с --net=host и никогда об этом не жалел.
Стандартная хешмапа для такого маленького набора строк ни разу не факт, что быстрее — вычисление хеша дороже, чем сравнение строк. Еще memory locality — хешмапа в плюсах построена на односвязных списках или с открытой адресацией?
Но универсальных решений все равно нет — вышеприведенный пример с большим if-ом, к примеру, имеет максимальное быстродействие, возвращая 4 сразу, как только найдет нужную строчку.
— массивы и односвязные списки
— сортировка пузырьком и вставками
— двоичный поиск
— деревья
Систему, которая заведомо устареет раньше, чем корабль. Так что почему бы и не XP.