<b>5 ошибок в Django, которые тихо ломают проект после первых 10 экранов</b>

<b>5 ошибок в Django, которые тихо ломают проект после первых 10 экранов</b>

— Логика размазывается по views: в итоге один endpoint и валидирует, и считает, и пишет в БД. Лучше сразу выносить бизнес-правила в сервисы или model methods, а view оставлять тонким слоем.
— Сигналы используют как универсальный клей. Для простых реакций это ок, но для важной бизнес-логики сигнал плохо читается и тяжело тестируется.
— На проде надеются на автогенерацию SQL из моделей и забывают про индексы, уникальные ограничения и select_related/prefetch_related. Потом лечат не баги, а медленные страницы.
— settings.py превращают в свалку констант. Нормальная схема — разделять конфиг по окружениям и хранить секреты отдельно, а не по привычке в репозитории.

Еще одна частая проблема — смешивать инфраструктуру и домен в одних и тех же модулях. Когда API, ORM, celery-задачи и утилиты лежат вперемешку, проект становится трудно сопровождать уже на втором спринте.

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