Проблемы подготовки прикладных разработчиков в современной России (Дмитрий Муканин, OSEDUCONF-2025)

Материал из 0x1.tv

Докладчик
Дмитрий Муканин

В современном мире прослеживаются чёткие тенденции: деградация технического образования, дефицит высококвалифицированных кадров и стремление компаний к снижению издержек. Именно по этому современные популярные технологии и фреймворки стараются снизить порог входа в разработку, что влечёт за собой тотальное снижение уровня компетентности программистов.

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

Видео

Презентация

Thesis

В погоне за снижением «порога входа» в разработку, на практике, с новыми технологиями и фреймворками такими как: Flutter, QML, React Native, Jetpack Compose и другими, мы получаем тотальное снижение уровня компетентности разработчиков. Зачастую разработчики остаются на том самом «пороге входа» и не развиваются дальше, система этого не предусматривает.

При снижении уровня компетентности, мы получаем приложения, которые всё более требовательны к железу и электроэнергии. Каждый новый фреймворк «высокого уровня» требует всё более производительных устройств для решения тех же задач. Это же касается и языков программирования «высокого уровня», таких как: Phyton, JavaScript, Dart[1].

Это же снижение компетентности ведёт к тому, что система больше не в состоянии делать по-настоящему сложные приложения, такие как: PLM, RM, PM, PDM, CAD, CAE, CAM, CAPP и тому подобные. Мы оказываемся завязаны на уже существующие бренды или, как минимум, уже существующие фреймворки.

Электроэнергия конечна. Особенно это заметно по требованиям для технологий с использованием искусственного интеллекта (далее ИИ), но и потребление ресурсов обычным железом тоже растёт. На сегодня, рост потребности в энергии не успевает за предложением, что легко заметить по росту тарифов во всём мире, включая Россию.

Задачи, которые пытаются решить с помощью ИИ, могли бы быть решены более энергоэффективно алгоритмически, будь для этого компетентные специалисты. Это касается. в первую очередь, задач статистического анализа, кластеризации, управления предприятием. Например, вместо использования ИИ-решения, как предлагает Дженсен Хуанг[2],можно использовать более простое решение на базе Steering behavior, экономя гигаваты вычислительных ресурсов.

Это также касается и представления данных. Вместо LLM имеет смысл использовать правильно организованную объектно – ориентированную БД, но правильно организовать её может только подготовленный специалист. ИИ здесь — затычка в дефиците кадров.

В отличии от специалиста, ИИ не развивается, не предлагает более глобальные решения, не создаёт собственные новые подходы. Для развития науки и техники костыль в виде ИИ — тупик, который выбивает среднее звено прикладных специалистов. А без этого среднего звена у нас не будет высшего звена.

Без развития собственной школы программирования, от низшего до высшего уровня, однажды мы упрёмся в энергетический кризис ИИ, из которого не сможем выбраться.

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

В условиях замкнутости разработок внутри России, они не развиваются. Мы видим это на практике, например, по процессору Эльбрус и его поддержке новых технологий — не поддерживается транслятор в LLVM IR. Рано или поздно, устаревание таких продуктов станет безнадёжным, и они исчезнут.

Исчезновение отечественных разработок во многом ставит нас под контроль других государств. Даже если мы сами обеспечиваем критические системы, другие страны через мобильные ОС, браузеры, пользовательские приложения и решения вроде Firebase, фактически, собирают досье на наших граждан, что даёт возможность их контролировать и провоцировать.

Для выхода из этой ситуации, отечественные продукты должны быть глобальными. А, значит, в том числе, поддерживать глобальные технологии, американские и китайские. Но, при этом, основываться на коде и системах под нашим контролем. Опять же, необходимы специалисты, которые способны этим заниматься системно, а не писать отдельные пользовательские приложения.

Отечественные разработчики ОС и другого большого софта не готовы поддерживать даже собственные версии зарубежных фреймворков[3]. Таким образом, единоразовое «портирование» быстро устареет, и обновлять софт, построенный на базе такого порта будет невозможным. Мы уже столкнулись с этим, например, для Qt. Без собственных квалифицированных разработчиков и собственного фреймворка эта проблема не решается.

Их можно понять, рабочее время специалиста дорогое, а специалистов мало. Ценовая конкуренция за специалистов активно развивается. Однако, эта конкуренция не решает проблему нехватки кадров, она её усугубляет, у людей с начальным уровнем подготовки формируются завышенные ожидания с одной стороны, и отпадает необходимость в саморазвитии, с другой.

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

Например, создание образовательно-практического консорциума, который одновременно бы и готовил специалистов для компаний по отечественным технологиям, и занимался развитием этих технологий на благо всех участников консорциума.

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

В качестве технологической основы для такой образовательной программы мы предлагаем использовать открытый отечественный кроссплатформенный фреймворк Stappler SDK. Фреймворк прост в освоении и подходит для обучения новых разработчиков широкого профиля, так как в основном использует стандартные подходы, принятые в индустрии. Данный проект ориентируется на максимальный охват платформ, в том числе Эльбрус, ARM (Байкал), RISC-V, потенциальные китайские и индийские процессоры. Поэтому в качестве основного языка используется С++, и предусмотрена возможность использовать другие языки через виртуальную машину WebAssembly. Для получения наиболее простого и эффективного API, во фреймворке объединяется классический подход к разработке на “старом” языке C++ с практиками, пришедшими из других систем и платформ. Заимствуются техники из Rust, Golang, Java, и, одновременно, практики программирования системного уровня вроде пулов памяти и невладеющих контейнеров. Фреймворк предназначен для разработки и обслуживания разнородных информационных систем, таких как: серверные приложения, мобильные и настольные приложения, автоматизированные рабочие места, средства автоматизации, средства тестирования и многие другие. Кроме того, Stappler SDK полностью адаптирован для различных отечественных ОС.


Примечания и ссылки

  1. Rui Pereira, Marco Couto, Francisco Ribeiro, Rui Rua, Jácome Cunha, João Paulo Fernandes, and João Saraiva, Ranking Programming Languages by Energy Efficiency, 2021
  2. CES 2025: AI Advancing at ‘Incredible Pace,’ NVIDIA CEO Says, https://blogs.nvidia.com/blog/ces-2025-jensen-huang/
  3. Как мы раскрыли внутреннюю архитектуру Flutter и затащили его на собственную платформу, — https://habr.com/p/864200/