7 ошибок в Django, которые тихо ломают проект и потом долго ищутся

7 ошибок в Django, которые тихо ломают проект и потом долго ищутся

Django кажется «безопасным по умолчанию», но в проде чаще всего стреляют не фреймворк, а привычки команды. За неделю в репах обычно всплывают одни и те же вещи:
— тяжелая логика в views и serializers вместо сервисного слоя;
— N+1-запросы из-за забытых select_related/prefetch_related;
— model.save() как место для всего подряд;
— отсутствие явных ограничений на уровне БД.

Еще одна частая зона боли — формы и валидация. Если проверка данных живет только в шаблоне или фронте, бэкенд начнет принимать мусор. Если валидация размазана между model clean, serializer и view, отладка превращается в квест. Лучше держать правило одно: критичные инварианты должны быть проверяемы в модели или на уровне базы, а остальное — в тонком слое приема данных.

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

Если в Django-проекте регулярно появляется «магия», значит пора резать слой ответственности. Чем меньше логики в view и чем больше явных ограничений в модели и БД, тем дешевле поддержка и быстрее поиск багов.