Django roadmap: что изучать для работы

Django в 2026-м не «устарел», и не «единственный правильный Python». Его всё ещё ставят туда, где нужны админка, формы, права доступа и предсказуемая серверная модель: внутренние кабинеты, CRM-подобные сервисы, личные кабинеты клиентов, контентные панели, B2B-инструменты. Вакансии с Django есть. Проблема не в рынке, а в roadmap, который выглядит как бесконечный список библиотек.

Ниже — объём, который реально закрывает junior и сильный intern на CIS-рынке: какой кусок языка обязателен, что уметь в ORM и авторизации, какой один проект собрать, как читать вакансии и когда Django уже не ваш вход. Это не курс «весь фреймворк за выходные» и не обещание оффера. Это карта под работу.

Коротко:

• Сначала Python и HTTP, потом Django. Иначе вы копируете туториал и не понимаете, куда падает запрос.
• На первой работе чаще нужны модели, админка, права, формы и простые API, а не «микросервисы на Celery с нуля».
• Один сервис с пользователями, ролями и админкой сильнее десяти блогов из гайда.
• DRF, Celery, Docker подключайте, когда базовый запрос-ответ уже ваш, а не «потому что так в roadmap картинке».
• Готовность к отклику — это проект со ссылкой плюс умение объяснить миграцию, N+1 и «кто может видеть эту страницу».

Зачем учить Django, а не «просто Python»

Python без веб-рамки на рынке чаще уходит в скрипты, данные или сопровождение чужого сервиса. Django — это конкретная роль: человек, который может собрать серверную часть продукта с админкой и не развалить данные. Если цель — войти как Python-разработчик в веб, Django или соседний FastAPI всё равно появятся в описании. Общий язык без веба — другая ветка, её лучше смотреть в Python roadmap, а не мешать с этой.

Django берут не за любовь к «батарейкам». Берут за скорость: модели, миграции, админка, сессии, права. Компании с внутренними панелями не хотят писать CRUD с нуля. Если вам ближе тонкий API без админки — честно смотрите FastAPI roadmap. Оба стека встречаются. Путать их в одном резюме «умею всё» — слабый ход.

Какой объём закрывает junior

Работодатель на входе почти никогда не ждёт, что вы с нуля спроектируете высоконагруженный биллинг. Он ждёт, что вы:

1. Поднимете проект, разберётесь в чужих приложениях, не сломаете миграции.
2. Добавите модель, форму или endpoint и покроете это тестом.
3. Настроите, кто видит объект: staff, обычный пользователь, аноним.
4. Не устроите N+1 в списке и не положите секрет в репозиторий.

Это скучный список. Именно он отличает человека после туториала от человека, которому можно дать тикет «добавь поле и фильтр в админке». Архитектура «сервис на сервис» и Kubernetes на первой Django-роли редко являются входным критерием. Если вакансия начинается с Kafka, k8s и «опыт 5 лет», это не junior-roadmap — это другой поиск.

Карта навыков: три слоя, не сорок библиотек

Слой 1. Язык и веб без фреймворка

Пока не уверенно пишете функции, списки, словари, исключения и читаете чужой код — Django будет магией. Нужны: виртуальное окружение, pip, модули, основы SQL (SELECT/JOIN/индекс на пальцах), HTTP-методы, статус-коды, cookies vs headers. Не надо «весь Computer Science». Надо объяснить, чем GET отличается от POST и почему пароль не логируют.

Слой 2. Ядро Django

• Проект и приложения. settings, urls, wsgi/asgi на уровне «куда смотреть», не на уровне написания своего сервера.
• Модели и миграции. поля, связи ForeignKey/M2M, makemigrations / migrate, откат через новую миграцию, не ручное правёние продакшен-таблицы.
• ORM без сюрпризов. filter/exclude, select_related/prefetch_related, агрегации по минимуму, транзакция на «создать заказ и позиции».
• Админка. list_display, фильтры, поиск, readonly, простые inlines. Это не стыдно: у многих продуктов админка — основной интерфейс сотрудников.
• Views и шаблоны или API. Для классического Django — CBV или FBV плюс формы. Для API-вакансий — serializers и viewsets, но после понимания request/response.
• Авторизация. User, login/logout, permissions, группы, is_staff. Свой User с телефоном — только если понимаете AbstractUser.
• Тесты. TestCase на создание объекта и на 403 для чужого пользователя. Один такой тест весит больше сертификата.

Слой 3. То, что добавляют по вакансии

DRF, Celery, Redis, PostgreSQL в Docker, простые сигналы, файлы в storage, логирование. Подключайте пункт, который есть в трёх вакансиях, на которые целитесь, а не «весь стек из картинки 2020 года». Если в ленте нет Celery — не ставьте его в центр roadmap.

Админка, ORM и авторизация: что именно уметь

Три темы, по которым на собеседовании отсеивают быстрее, чем по «что такое MTV».

Админка. Уметь зарегистрировать модель, скрыть поле, запретить удаление, показать связанный объект. Рассказать, почему админка — не «хак для джуна», а интерфейс для операций. Показать кастомный фильтр или действие — плюс, не обязаловка.

ORM. Уметь прочитать SQL в debug toolbar или query у queryset. Объяснить N+1 на примере списка заказов с клиентом. Знать, что get кидает исключение, а filter().first() — нет. Не путать null=True и пустую строку.

Авторизация. Разница authentication и authorization. Login required vs permission. Почему нельзя проверять «id в URL = мой id» только на клиенте. Объектные права: пользователь видит свои заказы, не чужие. Это и есть «закрыть junior», а не цитата из документации про middleware.

Какой проект собрать

Не блог. Не todo, который живёт в туториале. Соберите один сервис с ролями.

Рабочий бриф: «внутренняя панель заявок». Пользователь создаёт заявку. Менеджер меняет статус. Админ видит всех. Есть список, фильтр по статусу, детальная страница, админка, логин. Данные в PostgreSQL. README: как поднять, какие роли, что не сделано.

Это бьётся с реальными кабинетами сильнее, чем интернет-магазин «на миллион сущностей», где половина скопирована. Объём: 2–4 модели, не 20. Честно напишите, чего нет: оплаты, почты, очередей. Рекрутер это ценит. Как упаковать проект в файл — в резюме Python-разработчика и общем описании проектов.

Пример 1. 90 дней до отклика

Предположение: вы уже писали простые скрипты на Python, веба не было. 10–12 часов в неделю.

1. Дни 1–20. HTTP, SQL на уровне JOIN, git, один CRUD без Django — хоть на Flask в 80 строк, хоть на встроенном http.server плюс шаблон. Цель: понять запрос.
2. Дни 21–45. Официальный туториал Django один раз до конца. Затем выкинуть учебный polls и начать свою панель заявок. Модели, админка, логин.
3. Дни 46–65. Права: менеджер не удаляет пользователей. Список без N+1. Два теста. Деплой хотя бы на один понятный хостинг или Docker Compose локально с инструкцией.
4. Дни 66–90. По вакансиям добрать один пункт: DRF к той же панели или выгрузка CSV или простой сигнал на смену статуса. Резюме, 15 точечных откликов, не 150.

Если через 90 дней нет ссылки, которую можно открыть за минуту — roadmap не закончен, сколько бы курсов ни было пройдено.

Неделя 1–3: HTTP и SQL без фреймворка. Неделя 4–7: туториал Django один раз, затем своя панель заявок. Неделя 8–10: права, список без N+1, два теста. Неделя 11–13: один пункт из вакансий (DRF или CSV или Docker Compose) и 15 откликов под Django, не под «Python вообще».

Пример 2. Как читать вакансию Django

Вакансия: «Junior/Middle Python, Django, PostgreSQL, REST, знание админки, умение писать тесты. Плюс: DRF, Docker, Celery».

Разбор:

• Ядро: Django + PostgreSQL + тесты. Если этого нет в проекте — не откликайтесь «на потенциал».
• REST может значить и Django views с JSON, и DRF. В письме напишите, что именно у вас есть.
• Celery в плюсах — не блокер. Не тратьте месяц, если ядра ещё нет.
• Middle в заголовке при junior-стеке — часто «один человек в команду». Смотрите задачи, не слово Middle.

Откликаюсь на Python/Django в команду внутренней панели.

Собрал сервис заявок: роли пользователь/менеджер/админ, фильтры, админка, два теста на права. PostgreSQL, Django 5. REST пока через JSON-views, DRF в README как следующий шаг. Репозиторий: [ссылка]. Готов на созвоне разобрать миграцию и queryset списка.

Письмо короткое. Каркас как в письме без опыта, только факт — Django-сервис, не «прошёл курс».

Частые ошибки roadmap

• Туториал по кругу. Третий блог не считается новым опытом.
• Сразу DRF и микросервисы. Вы не объясните 403 на объекте.
• SQLite в резюме как «продакшен БД». Для учёбы нормально. Для вакансии с PostgreSQL поднимите Postgres хотя бы локально.
• Секреты в git. SECRET_KEY и пароль БД в репозитории — минус на скрининге.
• Копипаст settings без понимания DEBUG. На собеседовании спросят, почему нельзя DEBUG=True снаружи.
• Путать Django с «умею Python» в шапке. Если целитесь в данные — не та ветка. Если в веб — пишите Django явно.

Стек в резюме держите честным: что трогали руками, не что мелькало в видео. Как не раздувать строку технологий — в указании стека.

Когда Django уже не ваш вход

Если все вакансии вокруг — FastAPI, aiohttp, «highload», а Django только в легаси 2015 года без админки в задачах, не удерживайте фреймворк из упрямства. Если хотите frontend — Django не заменит React. Если любите пайплайны данных — берите SQL и Python без веба. Фреймворк должен совпадать с лентой, в которую вы откликаетесь, иначе roadmap превращается в хобби.

Смотреть живые формулировки удобно в каталоге Python-вакансий: выпишите 10 объявлений, отметьте Django / DRF / FastAPI / «админка». Дорожная карта строится из этой таблицы, не из чужого GitHub «awesome django».

Как выглядит собеседование по Django на входе

Скрининг часто короткий: Python, SQL, «поднимали ли сами проект». Затем просят экран и код. Типичные ходы, к которым стоит быть готовым без зубрёжки определений MTV:

• Покажите модель и миграцию: зачем поле, что будет, если задеплоить код без migrate.
• Список объектов с FK: где N+1 и как убрать prefetch/select_related.
• Пользователь открывает /orders/15/: где проверка «это его заказ».
• Чем get_object_or_404 лучше голого get в этом месте.
• Почему SECRET_KEY и пароль БД не в git, чем .env отличается от settings, закоммиченных «на время».

Если зовут на live coding, просите задачу в духе «добавь поле и фильтр», не олимпиаду. Олимпиада без Django в вакансии — другой отбор. Вопросы по языку рядом: вопросы на собеседовании Python. Навыки, которые имеет смысл явно перечислить в CV, не раздувая стек: навыки backend.

После скрининга имеет смысл прогнать резюме через разбор: на Django чаще врут админкой «настраивал» без единой кастомной колонки и пишут Celery, которого в репозитории нет. Лучше короче и правда, чем длинный список из вакансии мечты.

Частые вопросы

Что сделать сейчас

Откройте Python-вакансии, выпишите 8–10 с Django, отделите обязательное от «плюсов». Соберите или доведите один сервис с ролями, админкой и тестом на права. Затем резюме с этой ссылкой и коротким письмом под одну вакансию, не под «Python вообще».

Если проект уже есть, прогоните его через разбор резюме: часто проседает не код, а формулировка «что сделал я». Вопросы на интервью по языку имеет смысл смотреть заранее в вопросах на собеседовании Python — но только после того, как queryset списка заявок вы можете объяснить без шпаргалки.