В Python-разработке негласно существует два стека. Первый используют компании здесь и сейчас: проверенный, скучный и стабильный. Второй активно пушат медийные разработчики на конференциях и в своих тг-каналах — свежий, интересный и почти нигде не используемый. Но что реально нужно Python-разработчику из этого всего в 2026?
Сегодня разберём инструменты из обеих категорий: что реально требуют в вакансиях, что только набирает обороты, а что пока можно не учить, но вместо этого прокачать базу.
Какую версию Python используют в коммерческой разработке
Каждый год выходит новая версия Python — быстрее, с новыми фичами, и очень соблазнительно сразу поставить её на рабочий проект, только вот на практике так никто не делает.
Большинство компаний и проектов работают на Python 3.11-3.13. Задержка перед переходом на новую версию составляет примерно год-два. Когда выходит очередной релиз, рынок всё ещё сидит на предыдущем.
Здесь важно понять ключевую причину торможения: большинство Python-библиотек — это open-source продукты, написанные энтузиастами без какого-либо финансирования. Они просто не успевают обновляться с той же скоростью, что и сам язык. Часть библиотек и вовсе перестаёт поддерживаться — и в новой версии Python они не работают.
Плюс каждый новый релиз языка несёт поведенческие изменения. Встроенные модули переименовываются, устаревшие убираются. Если ваш проект использует что-то из списка удалённого — при переезде он просто сломается. А коммерческий продукт — это, как правило, сотни тысяч строк кода. Мигрировать такой объём на новую версию языка может занять у команды целую неделю. При этом прирост скорости в 10–15% бизнесу чаще всего безразличен: финансово это просто невыгодно.
На новых проектах в стартапах иногда встречается Python 3.13 или даже 3.14, возможно и 3.15 — но это исключение. Legacy-проекты на Python 3.8, 3.9 — это другая крайность, туда лучше не идти. Про Python 2 вообще молчим.
Какие базы данных используют Python-разработчики
MongoDB, DynamoDB, графовые базы — всё это регулярно мелькает в статьях и докладах, но в реальных вакансиях в СНГ ситуация другая.
Нереляционные базы данных до нас пока по-настоящему не добрались. Глобальный тренд на NoSQL существует, но в СНГ-разработке он пока не стал нормой, основным инструментом всё ещё считается — PostgreSQL, и он закрывает большинство задач.
Причин несколько:
- PostgreSQL — это реляционная база данных с поддержкой связей между таблицами, оператором JOIN, богатой системой индексов и двадцатилетней историей использования в продакшене.
- Он проверен, предсказуем и хорошо знаком большинству разработчиков.
- MySQL тоже присутствует на рынке, но PostgreSQL постепенно вытесняет его и увеличивает долю в нише.
Отдельная история — Redis. Называть его базой данных не совсем точно: это in-memory хранилище, то есть данные содержатся в оперативной памяти. Redis используется для кэширования — и является абсолютным лидером в этой роли. Альтернатива, Memcached, существует, но используется гораздо реже. Достаточно открыть hh.ru и сравнить количество вакансий — разница очевидна. При этом Redis популярен не только в Python: его применяют в Java, Golang и JavaScript-бэкенде.
PostgreSQL закроет практически все задачи. Cassandra, YDB, графовые базы — это под конкретные задачи, которые встречаются редко. Лезть туда раньше времени не стоит.
FastAPI или Django: что выбрать в 2026 году
Споры «что лучше» в Python-сообществе будут всегда. Каждые полгода кто-нибудь объявляет об «убийце FastAPI» или о возрождении Django, но реальность гораздо скучнее.
FastAPI и Django сегодня делят рынок вакансий примерно пополам.
- FastAPI занимает первое место по количеству вакансии, но отрыв от Django небольшой.
- Django при этом находится в состоянии стагнации — не растёт, но и не падает.
Flask, который ещё несколько лет назад был стандартным выбором для небольших проектов, сейчас планомерно теряет позиции: количество вакансий по нему заметно снижается уже полтора года. AIOHTTP также относится к малоиспользуемым фреймворкам.
Есть один случай, когда выбор без выбора: если проект строится на асинхронной архитектуре — это FastAPI. Django поддерживает асинхронность, но не идеально. Если же асинхронность не критична и нужен фреймворк из коробки — Django остаётся вполне рабочим вариантом.
Полезный блок со скидкой
Стек из этой статьи — это не список для изучения за выходные. FastAPI, PostgreSQL, Redis, Celery, SQLAlchemy, Pytest — каждый инструмент требует практики на реальных задачах. Если хочется разобраться, как всё это работает, — держите промокод Практикума на любой платный курс: KOD (можно просто нажать). Он даст скидку при покупке и позволит сэкономить на обучении.
Бесплатные курсы в Практикуме тоже есть — по всем специальностям и направлениям, начать можно в любой момент, карту привязывать не нужно, если что.
Как управляют зависимостями в Python-проектах
Когда разработчик заходит на новый проект, первое, что он делает — поднимает окружение. От того, насколько быстро это произойдёт, зависит не только настроение с утра, но и скорость деплоя на продакшн.
Стандарт для коммерческой разработки сегодня — Poetry. Он умеет управлять зависимостями без конфликтов версий, удобно переключает версию Python и разворачивает весь проект из одного конфигурационного файла — pyproject.toml, который сейчас является принятым стандартом оформления Python-проектов.
Примерно два-три года назад появился UV — менеджер, написанный на Rust. По скорости он кратно превосходит Poetry, PIP и Pipenv. Это имеет значение не только при локальной разработке: значительная часть времени в реальных проектах тратится на деплой — сборку Docker-образа, выкатку на стейдж, дев и продакшн. Когда установка зависимостей занимает несколько минут вместо десяти — это ощущается физически. UV по функциональности похож на Poetry: управление зависимостями, переключение версий Python, единый конфиг.
Но PIP пока остаётся абсолютным лидером. Poetry — один из нескольких популярных инструментов для управления зависимостями наряду с pip-tools и набирающим обороты UV. На собеседовании тему менеджера зависимостей поднимают редко — это не та область, где требуется глубокая подготовка.
Асинхронность, потоки и процессы: что реально используют
Если в 2020 году на многопоточность и мультипроцессинг смотрели как на стандартный инструмент Python-разработчика, то сейчас ситуация изменилась. Потоки и процессы никуда не исчезли, но постепенно отходят на второй план.
Топ-1 подход в новых проектах — асинхронность. Она подходит для любой задачи, где есть взаимодействие с внешними системами: запросы к базе данных, обращения к брокеру сообщений, работа с кэшом, вызовы внешних API. Именно такой тип нагрузки — ввод-вывод — встречается в веб-разработке и разработке телеграм-ботов чаще всего. Асинхронные приложения работают быстрее многопоточных на этих задачах и значительно проще в отладке: ошибки читаются и обрабатываются понятнее.
Потоки в явном виде — через модуль threading, с ручным созданием, джойном и закрытием — разработчики используют редко. Чаще они работают под капотом сторонних библиотек. Например, клиентская библиотека для ClickHouse работает через потоки, а не асинхронно — и разработчику приходится с этим мириться, потому что асинхронной альтернативы нет.
Мультипроцессинг остаётся актуальным в другом сегменте: ML-инженеры, дата-сайентисты и дата-инженеры используют процессы, чтобы распараллелить тяжёлые вычисления — там, где нужна не скорость I/O, а скорость CPU.
Архитектура: монолиты, микросервисы и паттерны
Архитектура — тема, которую на конференциях и в статьях обсуждают куда активнее, чем применяют на практике. Стоит понимать, чего ожидать от реальных проектов.
По приблизительным оценкам, монолиты используются примерно в 60% случаев, микросервисы — в 40%. Микросервисная архитектура действительно набирает обороты, но монолит никуда не уходит: он остаётся разумным выбором для небольших продуктов, которые поддерживают двое-четверо разработчиков. Нет смысла пилить сервис на микросервисы только потому, что это модно, — накладных расходов будет больше, чем пользы.
Архитектура самого приложения — чистая архитектура, DDD, гексагональная, слоистая — встречается в образцово-показательном виде в 5–10% реальных проектов. В остальных случаях используется что-то практичное и понятное: разделение на слои (роуты → сервисы → репозитории), паттерн репозитория для работы с базой данных. Этого достаточно для большинства задач. Бизнес не платит за архитектурную красоту — он платит за закрытые задачи.
Паттерны микросервисов — Saga, Transactional Outbox и подобные — на собеседованиях для стажёров, джунов и мидлов почти не поднимают. Это уже уровень Senior и Middle+, и то не везде. Архитектуру на таких позициях не проектируют — её наследуют и поддерживают.
Архитектура прокачивается постепенно, параллельно с работой. Тратить на неё 15–20% учебного времени — достаточно. Остальное лучше вложить в то, что реально спрашивают на собеседовании и требуют в задачах.
Линтеры и форматтеры: что стоит на рабочих проектах
Вопрос форматирования кода выглядит как технический, но на деле это ещё и командная политика. Без автоматических инструментов споры о лишнем отступе или длине строки съедают время на ревью.
Здесь важно разделить два класса инструментов.
- Форматировщики — например, Black — просто приводят код к единому виду по правилам PEP8 или настройкам команды. Они не трогают логику, только внешний вид.
- Линтеры, такие как Flake8 и PyLint, работают глубже: ищут неиспользуемые переменные, потенциальные ошибки и места, где код может сломаться в рантайме. PyLint при этом проходится по всей кодовой базе особенно тщательно.
На практике связка выглядит так: форматировщик запускается локально перед пушем в репозиторий — чтобы в GitLab или GitHub уходил уже причёсанный код. Линтер подключают на этапе CI/CD — как защитный барьер перед деплоем на продакшн. Самые распространённые связки в коммерческих проектах: Black + Flake8 или Black + PyLint.
Про Ruff слышали многие. Он написан на Rust, от той же команды, что сделала UV, работает очень быстро и объединяет в себе функции форматировщика, линтера и сортировщика импортов — заменяя сразу Black, Flake8, PyLint и isort. Звучит привлекательно, но в реальной разработке он пока встречается редко. Причина прозаичная: перевести проект на 100–200 тысяч строк с PyLint на Ruff — это не переключить настройку. Правила у них немного расходятся, часть правил PyLint в Ruff вообще отсутствует, и чтобы пайплайны CI/CD снова заработали чисто, команде придётся потратить время на правку кодовой базы. Ни один тимлид не пойдёт на это без глобальной причины, если текущий PyLint справляется.
Брокеры и очереди: RabbitMQ, Kafka, Celery, TaskIQ
Когда в системе появляется больше одного сервиса, они должны как-то общаться друг с другом. Прямые синхронные вызовы между сервисами быстро становятся проблемой при росте нагрузки. Для этого и нужны брокеры сообщений.
Схема работы простая: один сервис отправляет сообщение в брокер, брокер временно его хранит, затем доставляет другому сервису — и после доставки удаляет. Таким образом сервисы не зависят друг от друга напрямую и не ждут ответа синхронно.
В Python-разработке чаще всего используется RabbitMQ. Kafka более популярна в экосистемах Java и Golang, хотя в Python-проектах тоже встречается. NATS — заметно набирает обороты, но пока уступает по распространённости.
Отдельная задача — фоновые задачи внутри одного сервиса: генерация отчётов, отправка email, обработка загруженных файлов. Для этого используют очереди задач. Здесь картина однозначная: Celery — это стандарт. Ему больше 15 лет, он синхронный, работает через несколько процессов-воркеров. Celery Beat отвечает за периодические задачи по расписанию. Если открыть джоб-сайты и сравнить количество вакансий с упоминанием Celery и TaskIQ — разница очевидна.
TaskIQ появился недавно (менее пяти лет), он асинхронный и технически современнее. Но у него есть ограничение: тяжёлые задачи — генерация изображений, видеообработка, сложные отчёты — блокируют событийный цикл, что делает TaskIQ неподходящим для таких сценариев. Celery лишён этой проблемы: при необходимости внутрь синхронного воркера можно завернуть асинхронный код через обёртку. Это не идеально с точки зрения архитектуры, зато надёжно и предсказуемо.
Дополнительные библиотеки: SQLAlchemy, Pydantic, Pytest
Три библиотеки, которые встречаются почти в каждом серьёзном Python-проекте — вне зависимости от того, FastAPI это, Django или просто скрипт с телеграм-ботом.
SQLAlchemy — ORM для работы с реляционными базами данных, прежде всего с PostgreSQL. Вместо написания сырых SQL-запросов разработчик работает с привычными Python-классами и объектами. Поддерживает асинхронный режим, что критично для FastAPI-проектов. Знание SQLAlchemy — это фактически знание того, как устроена работа с базой данных в большинстве Python-бэкендов.
Pydantic используется для валидации и сериализации данных. В связке с FastAPI он работает по умолчанию и неотделим от него. Но Pydantic полезен и за пределами FastAPI: для хранения конфигураций, валидации входящих данных в ботах, замены стандартных датаклассов. В отличие от встроенного dataclasses, Pydantic не привязан к версии Python — его можно обновить независимо, не меняя интерпретатор.
Pytest — стандарт для тестирования. Юнит-тесты, интеграционные тесты, фикстуры, параметризация, скоупы — всё это Pytest. Встроенный unittest существует, но развивается медленнее и жёстко привязан к версии языка. В серьёзных проектах тесты пишут на Pytest. На собеседованиях понимание фикстур и параметризации — ожидаемый минимум. Есть проекты без тестов, обычно это либо самая ранняя стадия стартапа, когда продукт нужно выкатить за несколько месяцев, либо небольшие внутренние инструменты. В остальных случаях тесты есть, и они на Pytest.
Что с этим всем делать: актуальный стек Python-разработчика в 2026 году
Если свести всё написанное выше к одной мысли — она будет такой: разрыв между тем, о чём говорят на конференциях, и тем, что стоит на реальных проектах, больше, чем кажется. Ruff обсуждают активнее, чем используют. TaskIQ звучит современнее Celery, но вакансии с Celery никуда не делись. UV быстрее Poetry, но большинство команд пока не торопится переезжать.
Это не значит, что новое не нужно изучать. Значит другое: сначала — база, потом — эксперименты.
Для тех, кто только входит в профессию или перешёл на Python недавно, приоритеты выглядят так:
- Версия языка: Python 3.12, 3.13 или 3.14 — коммерческие проекты работают на предыдущей или предпредыдущей версии, не на последней.
- Базы данных: PostgreSQL — основная, закрывает подавляющее большинство задач. Redis — для кэширования, второй обязательный инструмент.
- Фреймворки: FastAPI — лидер по вакансиям на hh.ru, выбор для асинхронных проектов. Django — устойчивый второй, особенно в крупных компаниях и монолитах. Flask — третий, теряет позиции как основной фреймворк.
- Менеджер зависимостей: Poetry — стандарт коммерческой разработки. PIP — на небольших проектах и внутренних инструментах.
- Асинхронность: asyncio и async/await — обязательный навык для нового проекта на FastAPI.
- Брокеры и очереди: RabbitMQ — основной брокер для межсервисного взаимодействия. Celery — стандарт для фоновых задач, ~800–1 500 вакансий против нуля у TaskIQ.
- Дополнительные библиотеки: SQLAlchemy — для работы с PostgreSQL вместо сырых SQL-запросов. Pydantic — для валидации данных, неотделим от FastAPI. Pytest — стандарт тестирования.
- Линтеры и форматтеры: Black + Flake8 или Black + PyLint — самые распространённые связки на продакшн-проектах.
- DevOps-минимум: Docker — обязателен. CI/CD (GitLab) — знание пайплайнов ожидается на большинстве позиций.
Для тех, кто уже работает и хочет расти: смотрите не на инструменты, а на задачи. Если на текущем проекте нет тестов — напишите первые, это заметят. Если линтер не подключён к CI/CD — предложите. Если архитектура монолита начала разрастаться — это хороший момент, чтобы разобраться, где граница между сервисами и как её разграничить.
И последнее. Технологии в этом списке — не финальный ответ, а только ситуация рынка на 2026 год. Всегда следите за тем, что публикацию в вакансиях или читайте КОД — потому что мы это делаем за вас.
Бонус для читателей
Если вам интересно погрузиться в мир ИТ и при этом немного сэкономить, держите наш промокод на курсы Практикума. Он даст вам скидку при оплате, поможет с льготной ипотекой и даст безлимит на маркетплейсах. Ладно, окей, это просто скидка, без остального, но хорошая.
