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

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