7 основных ошибок, которые делают Django-разработчики

Коротко о том, какие бывают ошибки при разработке Django-приложений и как их избежать, чтобы не было мучительно больно

перевод статьи 7 Common Mistakes That Django Developers Make

Django — это мощный веб-фреймворк, но вместе с мощью приходит и ответственность. В этой статье мы расскажем о распространенных ошибках, которые допускают даже опытные разработчики Django, однако большинство успешных проектов Django рано или поздно должны с ними справиться.

Изобретенение велосипедов

Django имеет множество функций из коробки и гораздо больше возможностей дают сторонние пакеты. Попробуйте «погуглить» проблему, которую хотите решить, прежде чем что-то писать — возможно, уже существует многофункциональное решение.

Вы также можете использовать онлайн-каталог Django Projects, где категория «apps» (небольшие компоненты, используемые для создания проектов) насчитывает более 3200 проектов. Вот краткий образец интересных пакетов только с первых двух страниц листинга:

Бонусный совет: я настоятельно рекомендую начать новый проект Django с cookiecutter-django. Он поставляется с кастомной моделью пользователя, регистрацией через django-allauth, отправкой электронной почты через Anymail и многими другими настройками по умолчанию, связанными с безопасностью и развертыванием.

Монолитная структура приложения

Django — это слабо связанная платформа, которая не требует от вас создания веб-приложений каким-либо конкретным способом. У опытных разработчиков Django, однако, есть стандартный способ делать вещи.

Основной единицей веб-приложения Django является проект Django, который состоит из одного или нескольких приложений. Приложение Django — это автономный пакет, который должен делать только одно. Например, блог, приложение участия в чем-либо или календарь событий.

Приложения Django могут содержать модули Python, специфичные для Django модули (представления, URL-адреса, модели, формы и т. Д.), Статические файлы, миграции баз данных, команды управления, модульные тесты и многое другое. Вы должны разделить ваш проект на небольшие, многократно используемые приложения, используя простую логику.

\ecommerce_project      <= This is your Django project
    \cart               <= This is a Django cart app
    \checkout           <= This is a Django checkout app
    \products           <= This is a Django products app
    db.sqlite3          <= Your project database
    manage.py           <= Django project management utility

Используя такую структуру, связанные функциональные возможности будут ближе друг к другу, что позволит вам и вашей команде более четко видеть общую картину вашего приложения. Кроме того, вы можете экспортировать приложение в другой проект и использовать его снова, или даже опубликовать его в PyPi как модуль с открытым исходным кодом.

Написание толстых представлений и тонких моделей

Архитектура Django может быть описана как Model-Template-View (MTV) или Model-View-Template (MVT).

Model (модель) – это то, куда должна идти большая часть вашей бизнес-логики. Он определен в models.py и находится в каталоге приложения. Он также включает в себя запросы к базе данных, которые передают результаты в слои представления и шаблона.

View (представления) состоят из кода, который обрабатывает взаимодействие с пользователем, такое как отправка формы пользователем и формирование результатов из базы данных в соответствии с вашим шаблоном. Это определено в views.py.

Если вы не пишете логику приложения в моделях и не используете представления, это означает, что вы написали свой код в модели, основанной на представлении. Это делает представления «толстыми», а модель — «тониким». Модели должны быть толстыми, а виды — тонкими.

Вы должны также использовать собственные менеджеры. Например, пользовательский менеджер может предоставить метод with_counts (), который возвращает список всех объектов OpinionPoll, каждый с дополнительным атрибутом num_responses, который является результатом агрегированного запроса. Для большего количества идей, проверьте встроенный UserManager.

Слишком много запросов на представление или неоптимизированные запросы

ORM Django часто обвиняют в том, что он делает слишком много запросов или они неоптимизированы. Но мы видим, что это происходит с ORM и в других средах.

Реальная проблема в том, что мы часто не знаем о проблемах производительности и их источниках. Как только вы выясните, какие у вас узкие места, вы сможете выбрать правильный подход для их устранения. Здесь вы можете многое сделать, но, скорее всего, это будет так:

  • Исправить простые ORM-запросы (привет предварительная выборка)
  • Настройка и оптимизация запросов ORM
  • Добавьте кеширование в нужных местах
  • Предоставить больше ресурсов

django-debug-toolbar — замечательный инструмент отладки. Вы можете использовать его для отслеживания проблем с производительностью в SQL-запросах, запросах, шаблонах, кэше и т. Д. Этот небольшой пакет поможет вам быстро выявить проблемы. Я настоятельно рекомендую использовать его.

Избыточные поля моделей

Поскольку запросы не могут использовать вычисляемые столбцы, а добавление реального столбца — всего лишь «создание миграций», разработчики часто дублируют поля, которые по-разному представляют одни и те же данные.

Довольно скоро половина ваших записей модели Vehicles будет иметь is_motorcycle == True и wheel_count == 4, и вы не будете уверены, какому полю доверять (подсказка: ни одному).

С Django вы можете рефакторировать несогласованные свойства, подобные этим, с помощью декоратора @property. Однако, хотя ORM позволяет вам обращаться к столбцам как к свойствам, обратное неверно, поэтому вам придется вручную рефакторировать каждый запрос.

Отсутствие индексов в моделях

Даже опытные разработчики Django забывают об индексах. Пожалуйста, добавляйте индексы к своим моделям! С другой стороны, не индексируйте все, так как это замедлит вставки, обновления и удаления. Как правило, вам нужен индекс для всего, что вы будете использовать для фильтрации или присоединения. Проанализируйте ваши QuerySets, чтобы определить, где нужны индексы.

Непоследовательная проверка данных

Модели Django могут быть связаны с одной или несколькими «формами», которые используются для создания и обновления экземпляров модели. Форма имеет много действий по-умолчанию, в частности, проверки, которая контролируется свойствами модели. Фактически, многие свойства модели существуют только для управления поведением форм по-умолчанию.

Многие разработчики Django забывают, что модель можно модифицировать не только посредством ее формы. Они также забывают отслеживать, какие ограничения находятся где. Не-ноль? Это на модели. Определите выбор для поля, явно перечисляя, какие значения оно может иметь? Это на форме. Уникальность? На модели. И так далее.

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

Резюме

jango был создан, чтобы помочь создавать программное обеспечение как можно быстрее. Однако, когда вы спешите с добавлением новых функций, легко что-то забыть или потерять общую картину. В этой статье мы рассмотрим некоторые распространенные ошибки, которые часто совершают разработчики Django, и способы их избежать.

Этот контрольный список может быть полезен, даже если вы опытный разработчик Django, потому что ошибки, такие как не добавление индексов в модели или непоследовательная проверка данных, не ограничиваются только новыми разработчиками.

Если вам понравилась эта статья, вы должны почитать плюсы и минусы Django в качестве веб-фреймворка для разработчиков Python.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *