5 типовых ошибок в Django-проекте, которые потом ломают поддержку

5 типовых ошибок в Django-проекте, которые потом ломают поддержку

За неделю в репах обычно всплывает одно и то же: бизнес-логика расползается по views, сериализаторам и сигналам. В итоге непонятно, где менять правило и почему один и тот же сценарий работает по-разному в админке, API и фоновой задаче.

• Толстые models: в модель кладут всё подряд, включая HTTP-логику и доступ к внешним сервисам. Модель должна держать инварианты и доменные правила, а не знать про запросы и ответы.
• Сигналы как скрытая магия: удобны до первого дебага. Если действие важно для сценария, его лучше вызывать явно из сервиса или use-case слоя.
• Разные источники истины: когда статус объекта меняют и в форме, и в celery-task, и в ручном скрипте без единой функции, рано или поздно появится рассинхрон.

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

Правило простое: если изменение нельзя объяснить одной фразой, вынесите его в отдельный слой. Django хорошо терпит быстрый старт, но хуже всего переживает проект, где логика живёт везде сразу.