Синдром «двух кнопок»: почему современные фреймворки калечат мышление бэкендеров

Зайдите сегодня на любой популярный ИТ курс или откройте типичный туториал по бэкенд-разработке для начинающих. С первых же минут вас начнут учить одной и той же магии. Вам скажут: «Зачем забивать голову сложной теорией, архитектурой систем и внутренним устройством баз данных? Вот вам FastAPI, вот вам Django, Express или Spring Boot. Поставьте декоратор, напишите три строчки кода — и фреймворк сам поднимет веб-сервер, сам сгенерирует таблицы в СУБД, сам настроит маршрутизацию, валидацию и сериализацию данных».

Я сам регулярно сталкиваюсь с этим, когда открываю чужие репозитории или смотрю на тестовые задания новичков, но как такого фундамент оказывается очень хрупким.

В итоге за последние годы мы получили уникальное, но пугающее явление — огромную индустрию разработчиков, которые умеют виртуозно собирать конструкторы из готовых библиотек, но впадают в полный ступор, если из проекта убрать автоматику. Синдром «двух кнопок» стал главным скрытым кризисом современной разработки. Мы получили поколение инженеров, которые умеют пользоваться абстракциями, но не имеют понятия, как эти абстракции работают на уровне ОС, сети и железа.

Великая иллюзия простоты

Фреймворки создавались опытными синьор-инженерами и архитекторами для таких же синьор-инженеров. Их главная цель — автоматизировать рутину в огромных коммерческих проектах, чтобы не писать сотый раз один и тот же код авторизации, логирования или роутинга. Но когда новичок начинает свой путь в профессию сразу с тяжелого enterprise-фреймворка, его обучение превращается в банальный карго-культ. Он зазубривает конфигурационные файлы, аннотации и магические методы, вообще не понимая физику процессов. В результате формируется опасный когнитивный диссонанс. Разработчик искренне считает себя специалистом по бэкенду, потому что его приложение успешно отдаёт JSON в браузере, но он не способен ответить на базовые архитектурные вопросы:

• Как операционная система управляет сетевыми сокетами? Что происходит на уровне ядра Linux при классическом системном вызове accept(), и почему блокирующий ввод-вывод (I/O) моментально убьет производительность при росте нагрузок?

• Что происходит с потоками процессора, когда в очередь веб-сервера прилетает одновременно 10 000 тяжелых сетевых запросов? Как планировщик ОС тратит драгоценное время на постоянное переключение контекста и почему добавление новых ядер процессора не всегда решает проблему?

• Почему копеечный сервер на чистом коде без фреймворков способен выдавать колоссальный RPS, в то время как тяжелая enterprise-система, упакованная в три слоя Docker-контейнеров на облачном хостинге, начинает жрать гб RAM еще до того, как обработает первый реальный запрос?

Индустрия приучила нас к догме: «Железо стоит дёшево, память стоит копейки, любую кривую архитектуру и неоптимальный код можно просто залить деньгами, докупив мощностей на AWS или в облаке». Но на бюджетных VPS, в условиях жестких инфраструктурных ограничений или под реальным, несинтетическим хабраэффектом это мгновенно разбивается.

Как ORM отучает людей думать и убивает базы данных

Пожалуй, самый сокрушительный удар по инженерному мышлению начинающих бэкендеров нанесли современные ORM-системы (Object-Relational Mapping). Инструменты, которые автоматически переводят объекты из кода в таблицы реляционных баз данных. Маркетологи ИТ-курсов преподнесли это как великое спасение от «скучного, старого и сложного» языка SQL. Зачем учить синтаксис запросов, если можно просто вызвать метод класса?

Но за эту лень приходится платить полную цену. Начинающие разработчики, выросшие на ORM, полностью перестают понимать логику реляционных СУБД. Они не знают, что такое индексы (B-Tree, Hash), как работают каскадные связи, чем отличаются уровни изоляции транзакций (Read Committed, Repeatable Read) и почему выбор неправильного типа данных на уровне диска может замедлить поиск в таблице в десятки раз. Когда пг начинает лагать и выдавать задержки в несколько секунд, такие разработчики вместо оптимизации структуры самой бд начинают судорожно искать плагины для кэширования в самом фреймворке или тупо пихать Redis везде, где надо и не надо.

Вместо того чтобы управлять СУБД, бэкендер становится заложником, какой именно SQL-код фреймворк решит сгенерировать. И в 90% случаев, если кодом управляет новичок, ORM генерирует монструозные, неоптимальные запросы. Самый классический пример — проблема N+1. Когда вместо одного компактного запроса с JOIN приложение делает один запрос для получения списка родительских записей, а затем в цикле выполняет еще N отдельных запросов к бд для каждой связанной строки. На таблице из 100 записей это незаметно. На таблице из 50 000 строк это забивает очередь процессов, утилизирует процессор на 100% и укладывает сервер в OOM-killer.

Исход рынка труда: почему джуны не могут найти работу

Сегодня на рынке сложился парадокс, который активно обсуждается во всех проф сообществах. С одной стороны, выпускники онлайн-платформ годами не могут пройти даже первичный скрининг резюме и бьются за копеечные вакансии. С другой стороны, компании месяцами держат позиции открытыми и жалуются на жесточайший кадровый голод.

Причина проста: работодателям больше не нужны «операторы фреймворков». Тимлиды и техлиды устали нанимать людей, у которых в портфолио на GitHub лежат абсолютно одинаковые, шаблонные пет-проекты (типичные листы, интернет-магазины обуви или простые API для блогов), которые были просто под копирку из официальной документации фреймворка или видео на YouTube. Как только проект на реальной работе выходит за рамки стандартного шаблона и требует: Написать кастомную и сложную бизнес-логику, Оптимизировать сырой SQL-запрос, настроить неблокирующий ввод-вывод или низкоуровневую работу с сокетами и протоколами, понять почему в памяти зависают мертвые объекты и происходит утечка, «РАЗРАБОТЧИК ДВУХ КНОПОК» моментально расписывается в собственном бессилии, т.к в документации его фреймворка не было метода под эту нестандартную задачу.

Компании ищут инженеров, а рынок предлагает им пользователей чужого софта. Выход из этой ловушки требует усилий и готовности ковыряться в вещах, которые на первый взгляд кажутся «низкоуровневой нудятиной». Чтобы стать востребованным, нужно сознательно спускаться на уровень ниже

Только понимание фундаментальных, базовых принципов делает разработчика настоящим профессионалом. Технологии, модные библиотеки и хайповые фреймворки меняются каждые три-четыре года: то, что было на пике вчера, сегодня считается устаревшим хламом. Но принципы работы бд, компьютерных сетей, операционных систем и алгоритмов остаются неизменными последние тридцать лет, потратив время на базу, вы строите фундамент на будущее.