Python Web & Scripts — Django, FastAPI, скрипты

7 ошибок в Django, из-за которых проект тормозит даже на «простых» страницах — Тянуть всё через ORM без select_related и prefetch_related: на списках это быстро превращается в N+1 и лишние запросы к базе. — Держать тяжёлую логику во view: когда в одном месте и валидация, и расчёты, и отправка писем, код становится трудно тестировать и почти невозможно переиспользовать. — Игнорировать индексы и план запросов: фильтр по полю есть, а в таблице нет нормального индекса — дальше начинается «почему это так медленно». Ещё одна типовая проблема — хаотичные шаблоны. Если в template лезут условия на пол-экрана, проще вынести часть логики в методы модели, сервисный слой или template tags. И не забывайте про формы: clean() и clean_field() часто спасают от дублирования проверок в нескольких view. Финальный фильтр простой: если кусок кода сложно объяснить вслух за 20 секунд, его уже пора дробить. В Django это почти всегда окупается в сопровождении, скорости и количестве багов.

7 ошибок в Django, которые тихо ломают проект и потом долго ищутся Django кажется «безопасным по умолчанию», но в проде чаще всего стреляют не фреймворк, а привычки команды. За неделю в репах обычно всплывают одни и те же вещи: — тяжелая логика в views и serializers вместо сервисного слоя; — N+1-запросы из-за забытых select_related/prefetch_related; — model.save() как место для всего подряд; — отсутствие явных ограничений на уровне БД. Еще одна частая зона боли — формы и валидация. Если проверка данных живет только в шаблоне или фронте, бэкенд начнет принимать мусор. Если валидация размазана между model clean, serializer и view, отладка превращается в квест. Лучше держать правило одно: критичные инварианты должны быть проверяемы в модели или на уровне базы, а остальное — в тонком слое приема данных. Отдельно смотрите на миграции и admin. Опасный паттерн — делать большие изменения схемы и сразу тащить за ними бизнес-логику в том же релизе. Когда что-то падает, непонятно, сломала миграция, фоновые задачи или новая ветка кода. Разносите изменения по шагам и оставляйте путь отката. Если в Django-проекте регулярно появляется «магия», значит пора резать слой ответственности. Чем меньше логики в view и чем больше явных ограничений в модели и БД, тем дешевле поддержка и быстрее поиск багов.