Документы десятилетней давности - исключение. Такие документы редко где есть и редко бывает надобность их открывать, кроме того, готовые документы правильнее хранить в пдф на выходе.
Было время, у нас поставили всем либру на работе, потому как выделять деньги на офис от Майкрософт не захотели потому что ценник порядочны оказался, машин, к слову, более 300 штук, и помножить эти 300 компов нужно на 10000 рублей получается весьма порядочная сумма.
В итоге it отдает взял и поставил на все компы либру.
Началась "вонь": у меня дома Майкрософт офис, я делаю документ вот так, а тут он открывается "вот так", ПОСТАВЬТЕ МНЕ СРОЧНО МАЙКРОСОФТ ОФИС!!!!!
на вполне себе справедливое замечание: просто дома поставьте себе либру и пользуйтесь ей, был какой то тотальный игнор. Люди не хотели ставить себе либру не потому что она, допустим, плохо работает, а потому что потому. И, что так же смешно, они описывали "незаменимые" фичи офиса от Майкрософт, но сами ими никогда не пользовались.
К слову, когда нужно было работать с большими таблицами, то у либры скорость открытия файла, поиска по таблице была значительно выше.
Тут ещё такой момент что врят ли нужно будет в каком то приложении "моментально" отбирать права, это в основном только банкам и надо, но и у них - тоже самое с сикретами,
Для монолита вполне себе можно использовать jwt, да и мгновенно никто не запрещает отзывать токены.
Схема простая: refresh хранится в базе, и он по базе и проверяется. Хотим отозвать - помечаем как блок и refresh перестает работать. Если использовать чисто этот сценарий, то сессия потухнет в период времени до 10 - 15 минут.
Для отзыва access токена можно идти немного по другому пути, без бд, например, (это только пример а не истинна в последней инстанции) можно сделать список заблокированных access токенов, допустим через переменную окружения или типа того. Да даже через текстовый файл, это неважно. И сверять каждый раз все входящие access токены с этим списком, до тех пор, пока токен не протухнет. То бишь, ввести проверку на 10 - 15 минут. Учитывая что refresh уже заблокирован, access обновление не получит.
Типа того.
НО ВОТ БОЛЕЕ ПРАВИЛЬНЫЙ ВАРИАНТ:
Имеем два сикрета, на каждый токен,
В базе так же держим refresh и его обновление.
Меняем сикрет у access,
Абсолютно у всех пользователей протухнет access, они "пойдут" его менять, и у того кто имеет заблокированный refresh тот ничего не получит.
Вы упустили, скорее всего, хороших инженеров, а набрали, в итоге, хороших операторов нейросетей.
У меня был опыт работы с одной компанией, которая так же делает бессмысленные технические интервью.
Проблема была в том, что они так же на серьезных щах "умничают" на собеседованиях, рассказывают какие они крутые профи, но продукт, который они делают, работает отвратительно.
Возникает вопрос, а как такие профессионалы делают на столько отвратительный продукт? А очень просто: они отсеяли всех хороших инженеров. Потому как операторы нейросетей даже не смотрят на код, который им сгенерировала нейронка. Они его тупо не понимают. И не читают. Им банально лень читать, скопировал, вставил, о, работает. То что работает плохо он не понимает. Что бы прочитать код и разобраться в нем нужно, как минимум, время. Но на собеседованиях этого времени не дают. И тут приходит кандидат, который за секунды разбирает код. И находит все 34 ошибки. Гений, не иначе. (Сарказм).
Сколько я видел различных продуктов, столько я видел максимально тупых глюков этих продуктов умноженных на 10.
У меня вообще закралась мысль, что подобные интервью созданы специально, что бы бездари, которые пришли после 2 недельных курсов во время ковида не теряли места, а инженеры не могли найти нормальную работу.
Тот же Яндекс взять, у них тех собеседование проходит в режиме "быстрее - бегом", время на подумать? Нет, вы что, подумать ответ на вопрос нужно было ещё за час до самого вопроса. И сами интервьюеры там - школьники что ли.... Которые, например, на позицию сениора спрашивают "а что такое дата класс в котлин". Это идиотизм.
Меня сразу смутило название: физик.... А с каких пор физики занимаются подобными делами?
По поводу багов: ну есть где то баг, который никогда не увидят 99% пользователей? Ну и фиг с ним.
Помню, читал, когда то давно, mindcraft, который спонсировался microsoft уже тестировал web сервера windows nt и gnu/linux, типа он в 5 раз быстрее оказался. (Типа оказался), хотя независимые тестировщики указали что gnu/linux работает ни чуть ни хуже, а где то даже и лучше.
Автор проделал, без сомнения, большую работу, систематизируя свой подход. Однако, при ближайшем рассмотрении, он создал не систему отбора лучших инженеров, а элитный клуб для любителей олимпиадных задач и викторин на знание, который в современных реалиях абсолютно неэффективен.
Лайв-кодинг в блокноте - главный провал методики Это самая абсурдная и оторванная от жизни часть. Требовать писать код в онлайн-редакторе без привычной IDE - это как просить хирурга провести операцию перочинным ножом, а потом удивляться, что он не помнит точное латинское название каждого инструмента.
Проверка памяти, а не интеллекта. Современная разработка - это не про запоминание всех методов Collectors или сигнатур функций. Это про умение решать бизнес-задачи с помощью инструментов. IDE - наш главный инструмент. Отказывая в нём, интервьюер проверяет не способность мыслить, а банальную зубрежку.
Искусственный стресс. Никто не пишет код в таких условиях. Это искусственно созданная стрессовая ситуация, которая отсеивает не плохих разработчиков, а тех, кто хуже справляется с бессмысленным давлением.
Игнорирование реальности. Автор сам пишет про Spring Boot, Hibernate, Kotlin. Все эти технологии подразумевают активное использование IDE для навигации, автодополнения и рефакторинга. Заставлять писать на них код вслепую - это полный нонсенс и демонстрация непонимания рабочего процесса.
Гонка вооружений с нейросетями, которую невозможно выиграть Автор создает настолько сложные и "хитрые" задачи, что сам же толкает кандидатов на жульничество.
Стимуляция обмана. Чем сложнее и академичнее задача, тем выше соблазн быстро "спросить" у ChatGPT. В итоге соревнование идет не в знаниях, а в скорости и незаметности использования нейросетей.
Неверный результат. Вместо того чтобы нанять человека, который умеет рассуждать, компания нанимает лучшего "оператора" нейросети. Автор жалуется на некомпетентность, но его же система и способствует ее сокрытию.
"Хитрые" SQL-задачи и Code Review как поиск "пасхалок" Подход к базам данных и ревью кода страдает той же болезнью - фокусом на эзотерических знаниях, а не на практической ценности.
SQL-акробатика. Автор сам признает, что большинство использует ORM, но упорно продолжает гонять кандидатов по "оконным функциям" и "хитрым группировкам". Да, это полезно знать, но для 95% задач бэкенд-разработчика это не является ключевым навыком. Гораздо важнее уметь спроектировать нормальную модель данных, а не написать монструозный запрос, который потом никто не сможет поддерживать.
Ревью ради ревью. Задача ревью - улучшить код и помочь коллеге, а не сыграть в "найди 10 отличий" с кодом, который нарочно написан как можно хуже. Этот "фрагмент реальной enterprise-системы" выглядит как свалка всех возможных анти-паттернов. Хороший инженер может не найти все 34 "ошибки", потому что в реальной жизни он бы написал этот код совершенно иначе с самого начала.
Итог: Кого на самом деле ищет автор? Эта система отбирает людей, которые:
Обладают феноменальной памятью.
Отлично справляются с бессмысленным стрессом.
Имеют опыт решения олимпиадных задач.
Либо очень хорошо умеют жульничать.
Но являются ли они лучшими командными игроками, архитекторами и инженерами, способными создавать и поддерживать сложные системы? Очень сомнительно.
В погоне за "идеальным" кандидатом, который знает наизусть все тонкости SQL и JDK, автор рискует упустить десятки отличных, прагматичных инженеров, которые просто хотят делать свою работу с помощью современных инструментов, а не сдавать экзамены из прошлого века.
А насчёт авторской разработки - лукавство, это скорее базовая модель, как раз в учебных целях она и применяется. Когда на занятиях берут и тестируют датчик, на определенном расстоянии что бы загорелся светодиод.
Я про "уж чья бы корова мычала", потому что WhatsApp там у себя делает ровно тоже самое что и max. Но, по отношению к нам, включил режим "вынепанимаетеэтодругое",
Про рефакторинг: Можно сразу строить космодром, когда нужна просто взлетная полоса для кукурузника. Логичнее сначала подтвердить жизнеспособность архитектуры, а потом её полировать. Это нормальный процесс разработки, а не "списание времени".
Насчет "сделать сразу нормально": попытка вылизать каждую строчку до идеала на этапе набросков часто приводит к оверинжинирингу.
"Сразу правильно может затормозить процесс потому что:
Избыточные абстракции. Трата время на создание универсальных интерфейсов для функций, которые в будущем могут вообще измениться или пойти под нож.
Паралич конфигурации. Вместо того чтобы проверить логику авторизации, можно полдня потратить на возню с иерархией yml-конфигов и @ConfigurationProperties.
Хрупкие тесты: Если покрыть тестами сырой прототип, то при любом изменении логики (которое в начале пути неизбежно) придется переписывать и код, и гору тестов. В итоге работа замедляется вдвое.
Поэтому сейчас важнее проверить жизнеспособность связей между сервисами. А когда архитектура устаканится, можно навести марафет, что в уже стабильном коде будет в разы быстрее и эффективнее, чем переделывать "идеальный" код по несколько раз.
Про Spring Security: Он нужен как мощный каркас - управление сессиями, CORS, CSRF, защита эндпоинтов и иерархия доступов. Написать свой фильтр внутри этого каркаса - это не "изобретение велосипеда", а настройка инструмента под свои задачи, например, хранение Refresh в БД. Одно другому не мешает, а дополняет.
Некоторые решения в этой части, в прошлой, и в последующих, например, использование @Value вместо @ConfigurationProperties или отсутствие тестов сделаны сознательно для упрощения разработки и наглядности. Сейчас моя цель собрать и зафиксировать рабочий "скелет" системы. Как только основная логика будет готова, я планирую отдельный этап рефакторинга, где буду закрывать этот "технический долг": переводить конфиги на типизированные классы, исправлять мелкие недочеты в JPA-запросах и покрывать всё тестами.
Про @ConfigurationProperties согласен, это более правильный путь для группировки настроек. В текущем варианте использовал @Value для наглядности в рамках статьи, но для продакшена - однозначно перееду на проперти-классы.
Про COALESCE и пустой результат: Справедливое замечание. Действительно, если записи нет, Spring Data может вернуть false по умолчанию, что даст ложноположительный результат. Это критический момент, буду пересматривать логику на возвращение Optional или проверку через exists.
Про фильтр и "коробочные" решения: Spring Security позволяет многое конфигурировать, но при использовании кастомных Refresh-токенов в БД и специфической логики валидации, свой фильтр дает больше прозрачности и гибкости. Хотя всегда есть куда упрощать.
Сейчас тестировать "чистые" функции генерации строк - это трата времени для прототипа. А вот когда логика обрастет связями, например, сложная ротация токенов или проверка ролей, я сделаю отдельный пост про интеграционное тестирование всего флоу авторизации сразу.
Понятие сложности всегда субъективно. Для тех, кто годами пишет на Spring, это действительно базовые вещи. Но если смотреть на статью как на старт цикла по проектированию архитектуры с нуля со всеми вытекающими компромиссами, то для многих разработчиков уровень входа выше среднего.
Метка стоит скорее как индикатор того, что это не просто "hello world", а начало работы над комплексной системой. Подкапотные разборы и более тонкие нюансы производительности как раз пойдут дальше по мере усложнения проекта
Понятие сложности всегда субъективно. Для тех, кто годами пишет на Spring, это действительно базовые вещи. Но если смотреть на статью как на старт цикла по проектированию архитектуры с нуля со всеми вытекающими компромиссами, то для многих разработчиков уровень входа выше среднего.
Метка стоит скорее как индикатор того, что это не просто "hello world", а начало работы над комплексной системой. Подкапотные разборы и более тонкие нюансы производительности как раз пойдут дальше по мере усложнения проекта
Документы десятилетней давности - исключение. Такие документы редко где есть и редко бывает надобность их открывать, кроме того, готовые документы правильнее хранить в пдф на выходе.
Меня позиция адептов Майкрософта всегда удивляла,
Было время, у нас поставили всем либру на работе, потому как выделять деньги на офис от Майкрософт не захотели потому что ценник порядочны оказался, машин, к слову, более 300 штук, и помножить эти 300 компов нужно на 10000 рублей получается весьма порядочная сумма.
В итоге it отдает взял и поставил на все компы либру.
Началась "вонь": у меня дома Майкрософт офис, я делаю документ вот так, а тут он открывается "вот так", ПОСТАВЬТЕ МНЕ СРОЧНО МАЙКРОСОФТ ОФИС!!!!!
на вполне себе справедливое замечание: просто дома поставьте себе либру и пользуйтесь ей, был какой то тотальный игнор. Люди не хотели ставить себе либру не потому что она, допустим, плохо работает, а потому что потому. И, что так же смешно, они описывали "незаменимые" фичи офиса от Майкрософт, но сами ими никогда не пользовались.
К слову, когда нужно было работать с большими таблицами, то у либры скорость открытия файла, поиска по таблице была значительно выше.
А в чем проблема просто везде поставить либру и пользоваться только ей? Вы же знаете что за каждую копию офиса от Майкрософт вы платите деньги?
Тут ещё такой момент что врят ли нужно будет в каком то приложении "моментально" отбирать права, это в основном только банкам и надо, но и у них - тоже самое с сикретами,
Для монолита вполне себе можно использовать jwt, да и мгновенно никто не запрещает отзывать токены.
Схема простая: refresh хранится в базе, и он по базе и проверяется. Хотим отозвать - помечаем как блок и refresh перестает работать. Если использовать чисто этот сценарий, то сессия потухнет в период времени до 10 - 15 минут.
Для отзыва access токена можно идти немного по другому пути, без бд, например, (это только пример а не истинна в последней инстанции) можно сделать список заблокированных access токенов, допустим через переменную окружения или типа того. Да даже через текстовый файл, это неважно. И сверять каждый раз все входящие access токены с этим списком, до тех пор, пока токен не протухнет. То бишь, ввести проверку на 10 - 15 минут. Учитывая что refresh уже заблокирован, access обновление не получит.
Типа того.
НО ВОТ БОЛЕЕ ПРАВИЛЬНЫЙ ВАРИАНТ:
Имеем два сикрета, на каждый токен,
В базе так же держим refresh и его обновление.
Меняем сикрет у access,
Абсолютно у всех пользователей протухнет access, они "пойдут" его менять, и у того кто имеет заблокированный refresh тот ничего не получит.
Вот и все.
Вы просто плохо читали правила тетради. Там, перед смертью, можно заставить человека что то сделать.
Поэтому нужно написать что то в стиле: "разблокировать Ютуб и телеграм потом повеситься".
Вы упустили, скорее всего, хороших инженеров, а набрали, в итоге, хороших операторов нейросетей.
У меня был опыт работы с одной компанией, которая так же делает бессмысленные технические интервью.
Проблема была в том, что они так же на серьезных щах "умничают" на собеседованиях, рассказывают какие они крутые профи, но продукт, который они делают, работает отвратительно.
Возникает вопрос, а как такие профессионалы делают на столько отвратительный продукт? А очень просто: они отсеяли всех хороших инженеров. Потому как операторы нейросетей даже не смотрят на код, который им сгенерировала нейронка. Они его тупо не понимают. И не читают. Им банально лень читать, скопировал, вставил, о, работает. То что работает плохо он не понимает. Что бы прочитать код и разобраться в нем нужно, как минимум, время. Но на собеседованиях этого времени не дают. И тут приходит кандидат, который за секунды разбирает код. И находит все 34 ошибки. Гений, не иначе. (Сарказм).
Сколько я видел различных продуктов, столько я видел максимально тупых глюков этих продуктов умноженных на 10.
У меня вообще закралась мысль, что подобные интервью созданы специально, что бы бездари, которые пришли после 2 недельных курсов во время ковида не теряли места, а инженеры не могли найти нормальную работу.
Тот же Яндекс взять, у них тех собеседование проходит в режиме "быстрее - бегом", время на подумать? Нет, вы что, подумать ответ на вопрос нужно было ещё за час до самого вопроса. И сами интервьюеры там - школьники что ли.... Которые, например, на позицию сениора спрашивают "а что такое дата класс в котлин". Это идиотизм.
Меня сразу смутило название: физик.... А с каких пор физики занимаются подобными делами?
По поводу багов: ну есть где то баг, который никогда не увидят 99% пользователей? Ну и фиг с ним.
Помню, читал, когда то давно, mindcraft, который спонсировался microsoft уже тестировал web сервера windows nt и gnu/linux, типа он в 5 раз быстрее оказался. (Типа оказался), хотя независимые тестировщики указали что gnu/linux работает ни чуть ни хуже, а где то даже и лучше.
Вот эта статья что то подобное мне напоминает.
Автор проделал, без сомнения, большую работу, систематизируя свой подход. Однако, при ближайшем рассмотрении, он создал не систему отбора лучших инженеров, а элитный клуб для любителей олимпиадных задач и викторин на знание, который в современных реалиях абсолютно неэффективен.
Лайв-кодинг в блокноте - главный провал методики Это самая абсурдная и оторванная от жизни часть. Требовать писать код в онлайн-редакторе без привычной IDE - это как просить хирурга провести операцию перочинным ножом, а потом удивляться, что он не помнит точное латинское название каждого инструмента.
Проверка памяти, а не интеллекта. Современная разработка - это не про запоминание всех методов Collectors или сигнатур функций. Это про умение решать бизнес-задачи с помощью инструментов. IDE - наш главный инструмент. Отказывая в нём, интервьюер проверяет не способность мыслить, а банальную зубрежку.
Искусственный стресс. Никто не пишет код в таких условиях. Это искусственно созданная стрессовая ситуация, которая отсеивает не плохих разработчиков, а тех, кто хуже справляется с бессмысленным давлением.
Игнорирование реальности. Автор сам пишет про Spring Boot, Hibernate, Kotlin. Все эти технологии подразумевают активное использование IDE для навигации, автодополнения и рефакторинга. Заставлять писать на них код вслепую - это полный нонсенс и демонстрация непонимания рабочего процесса.
Гонка вооружений с нейросетями, которую невозможно выиграть Автор создает настолько сложные и "хитрые" задачи, что сам же толкает кандидатов на жульничество.
Стимуляция обмана. Чем сложнее и академичнее задача, тем выше соблазн быстро "спросить" у ChatGPT. В итоге соревнование идет не в знаниях, а в скорости и незаметности использования нейросетей.
Неверный результат. Вместо того чтобы нанять человека, который умеет рассуждать, компания нанимает лучшего "оператора" нейросети. Автор жалуется на некомпетентность, но его же система и способствует ее сокрытию.
"Хитрые" SQL-задачи и Code Review как поиск "пасхалок" Подход к базам данных и ревью кода страдает той же болезнью - фокусом на эзотерических знаниях, а не на практической ценности.
SQL-акробатика. Автор сам признает, что большинство использует ORM, но упорно продолжает гонять кандидатов по "оконным функциям" и "хитрым группировкам". Да, это полезно знать, но для 95% задач бэкенд-разработчика это не является ключевым навыком. Гораздо важнее уметь спроектировать нормальную модель данных, а не написать монструозный запрос, который потом никто не сможет поддерживать.
Ревью ради ревью. Задача ревью - улучшить код и помочь коллеге, а не сыграть в "найди 10 отличий" с кодом, который нарочно написан как можно хуже. Этот "фрагмент реальной enterprise-системы" выглядит как свалка всех возможных анти-паттернов. Хороший инженер может не найти все 34 "ошибки", потому что в реальной жизни он бы написал этот код совершенно иначе с самого начала.
Итог: Кого на самом деле ищет автор?
Эта система отбирает людей, которые:
Обладают феноменальной памятью.
Отлично справляются с бессмысленным стрессом.
Имеют опыт решения олимпиадных задач.
Либо очень хорошо умеют жульничать.
Но являются ли они лучшими командными игроками, архитекторами и инженерами, способными создавать и поддерживать сложные системы? Очень сомнительно.
В погоне за "идеальным" кандидатом, который знает наизусть все тонкости SQL и JDK, автор рискует упустить десятки отличных, прагматичных инженеров, которые просто хотят делать свою работу с помощью современных инструментов, а не сдавать экзамены из прошлого века.
А на что фотографировали? На зенит какой нибудь?
А насчёт авторской разработки - лукавство, это скорее базовая модель, как раз в учебных целях она и применяется. Когда на занятиях берут и тестируют датчик, на определенном расстоянии что бы загорелся светодиод.
Хм.... Может я чего то не понимаю, но в чем проблема поднять свой сервер с бд? Хотя бы облачный vps и поставить на него postgre.
Или дело в цене? На сколько облачный сторонний должен быть дешевле и на сколько оправдано его использовать?
Я про "уж чья бы корова мычала", потому что WhatsApp там у себя делает ровно тоже самое что и max. Но, по отношению к нам, включил режим "вынепанимаетеэтодругое",
Вот уж кто бы, а WhatsApp пишет про частное и безопасное общение. Это же тот самый WhatsApp, который Пентагону сливает просто все что можно слить, да?
Я вообще не вижу абсолютно никакого смысла в использовании собственными продуктами от Microsoft.
Я, конечно, понимаю что люди привыкли, но год из года наступать на одни и те же грабли, при этом даже не пытаясь перейти на альтернативу...
Вас тоже благодарю, иногда и я ошибаюсь,
Про рефакторинг: Можно сразу строить космодром, когда нужна просто взлетная полоса для кукурузника. Логичнее сначала подтвердить жизнеспособность архитектуры, а потом её полировать. Это нормальный процесс разработки, а не "списание времени".
Насчет "сделать сразу нормально": попытка вылизать каждую строчку до идеала на этапе набросков часто приводит к оверинжинирингу.
"Сразу правильно может затормозить процесс потому что:
Избыточные абстракции. Трата время на создание универсальных интерфейсов для функций, которые в будущем могут вообще измениться или пойти под нож.
Паралич конфигурации. Вместо того чтобы проверить логику авторизации, можно полдня потратить на возню с иерархией yml-конфигов и @ConfigurationProperties.
Хрупкие тесты: Если покрыть тестами сырой прототип, то при любом изменении логики (которое в начале пути неизбежно) придется переписывать и код, и гору тестов. В итоге работа замедляется вдвое.
Поэтому сейчас важнее проверить жизнеспособность связей между сервисами. А когда архитектура устаканится, можно навести марафет, что в уже стабильном коде будет в разы быстрее и эффективнее, чем переделывать "идеальный" код по несколько раз.
Про Spring Security: Он нужен как мощный каркас - управление сессиями, CORS, CSRF, защита эндпоинтов и иерархия доступов. Написать свой фильтр внутри этого каркаса - это не "изобретение велосипеда", а настройка инструмента под свои задачи, например, хранение Refresh в БД. Одно другому не мешает, а дополняет.
Важное уточнение по коду:
Некоторые решения в этой части, в прошлой, и в последующих, например, использование @Value вместо @ConfigurationProperties или отсутствие тестов сделаны сознательно для упрощения разработки и наглядности. Сейчас моя цель собрать и зафиксировать рабочий "скелет" системы. Как только основная логика будет готова, я планирую отдельный этап рефакторинга, где буду закрывать этот "технический долг": переводить конфиги на типизированные классы, исправлять мелкие недочеты в JPA-запросах и покрывать всё тестами.
Про @ConfigurationProperties согласен, это более правильный путь для группировки настроек. В текущем варианте использовал @Value для наглядности в рамках статьи, но для продакшена - однозначно перееду на проперти-классы.
Про COALESCE и пустой результат: Справедливое замечание. Действительно, если записи нет, Spring Data может вернуть false по умолчанию, что даст ложноположительный результат. Это критический момент, буду пересматривать логику на возвращение Optional или проверку через exists.
Про фильтр и "коробочные" решения: Spring Security позволяет многое конфигурировать, но при использовании кастомных Refresh-токенов в БД и специфической логики валидации, свой фильтр дает больше прозрачности и гибкости. Хотя всегда есть куда упрощать.
Сейчас тестировать "чистые" функции генерации строк - это трата времени для прототипа. А вот когда логика обрастет связями, например, сложная ротация токенов или проверка ролей, я сделаю отдельный пост про интеграционное тестирование всего флоу авторизации сразу.
не туда написал,
Понятие сложности всегда субъективно. Для тех, кто годами пишет на Spring, это действительно базовые вещи. Но если смотреть на статью как на старт цикла по проектированию архитектуры с нуля со всеми вытекающими компромиссами, то для многих разработчиков уровень входа выше среднего.
Метка стоит скорее как индикатор того, что это не просто "hello world", а начало работы над комплексной системой. Подкапотные разборы и более тонкие нюансы производительности как раз пойдут дальше по мере усложнения проекта
Понятие сложности всегда субъективно. Для тех, кто годами пишет на Spring, это действительно базовые вещи. Но если смотреть на статью как на старт цикла по проектированию архитектуры с нуля со всеми вытекающими компромиссами, то для многих разработчиков уровень входа выше среднего.
Метка стоит скорее как индикатор того, что это не просто "hello world", а начало работы над комплексной системой. Подкапотные разборы и более тонкие нюансы производительности как раз пойдут дальше по мере усложнения проекта