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

Давайте программировать!

Ошибка №1: полагаться на глобальную системную среду Python для зависимостей проекта

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

Эту ошибку часто допускают начинающие разработчики Python и Django, которые не знакомы с возможностями изоляции среды в Python.

Существует несколько способов изоляции вашей среды, наиболее распространенными из которых являются следующие:

  • virtualenv — это пакет Python, позволяющий создать отдельную папку среды Python. Он предоставляет сценарии для активации и деактивации среды, а также для управления установленными пакетами Python в этой среде. Этот метод получил широкое распространение благодаря своей простоте и эффективности.
  • virtualenvwrapper: пакет Python, который устанавливается глобально и предоставляет набор инструментов для создания/удаления/активации и т. д. виртуальные среды. Все виртуальные среды хранятся в одной папке (которую можно переопределить с помощью переменной среды WORKON_HOME). Я не вижу никаких преимуществ в использовании virtualenvwrapper вместо virtualenv.
  • Контейнеры, особенно Docker, приобрели значительную популярность в последние годы, и я также нахожу их ценными во многих проектах, особенно в тех, которые создаются с нуля. Docker предлагает множество мощных функций и поддерживается богатой экосистемой сторонних инструментов для автоматизации контейнеров. Одним из заметных преимуществ Docker является возможность кэширования слоев, что значительно ускоряет процесс перестроения контейнеров.

Ошибка №2: Писать полные взгляды и худые модели

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

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

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

Ошибка №3: Огромный неуправляемый файл настроек

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

Хотя вы можете вручную разделить файл конфигурации и создать собственные загрузчики для решения этой проблемы, я хотел бы познакомить вас с Django Split Settings, надежным и хорошо протестированным пакетом Python, с которым я работал совместно. автор.

Пакет предоставляет две функции — optional и include, которые поддерживают подстановочные знаки для путей и импортируют ваши файлы конфигурации в том же контексте. Django Split Settings упрощает процесс создания вашей конфигурации, используя объявленные записи конфигурации из ранее загруженных файлов. Пакет легко интегрируется в ваш проект Django, не влияя на его производительность. Независимо от того, работаете ли вы над небольшим или крупномасштабным проектом, Django Split Settings можно легко включить в любой проект.

Посмотрите пример минимальной конфигурации:

from split_settings.tools import optional, include

include(
    'components/base.py',
    'components/database.py',
    'components/*.py',

    # the project different envs settings
    optional('envs/devel/*.py'),
    optional('envs/production/*.py'),
    optional('envs/staging/*.py'),
    
    # for any local settings
    optional(‘local_settings.py'),
)

Ошибка №4: STATICFILES_DIRS и STATIC_ROOT сбивают с толку начинающих разработчиков Django

Статические файлы относятся к активам, таким как JavaScript, CSS, изображения, шрифты и т. д., которые остаются неизменными на протяжении всего использования приложения. В Django эти статические файлы обычно собираются или «собираются» в общедоступный каталог в процессе развертывания.

В режиме разработки — python manage.py runserver — Django ищет статические файлы, используя параметр STATICFILES_FINDERS. По умолчанию он пытается найти запрошенный статический файл в папках, перечисленных в настройке STATICFILES_DIRS. В случае сбоя Django пытается найти файл, используя django.contrib.staticfiles.finders.AppDirectoriesFinder, который просматривает папку static каждого установленного приложения в проекте. Этот подход позволяет разрабатывать повторно используемые приложения, которые поставляются в комплекте с собственным набором статических файлов.

В производственной среде вы обычно обслуживаете свои статические файлы с помощью отдельного веб-сервера, такого как Nginx. Веб-сервер не знает о конкретной структуре вашего проекта Django или расположении статических файлов в нем. К счастью, Django предоставляет вам команду управления сбором статических данных python manage.py collectstatic, которая проходит через STATICFILES_FINDERS и копирует все статические файлы из папок приложений static и папок, перечисленных в STATICFILES_DIRS, в каталог, указанный вами в настройке STATIC_ROOT. Этот подход позволяет разрешать статические файловые ресурсы, используя ту же логику, что и сервер режима разработки Django, обеспечивая согласованность в разных средах. Кроме того, он централизует все статические файлы в одном месте, что упрощает их эффективное обслуживание веб-сервером.

Не забудьте запустить collectstatic в рабочей среде!

Ошибка №5: Не закреплять зависимости проекта в файле requirements.txt

Каждый новый проект Python должен начинаться с файла requirements.txt и новой изолированной среды. Обычно вы устанавливаете все пакеты через pip/easy_install, но никогда не забывайте добавлять их и в свой файл requirements.txt. Это упрощает процесс развертывания на серверах и позволяет участникам группы легко настроить проект на своих компьютерах.

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

Всегда закрепляйте свои пакеты для производства! Лично я использую очень хороший инструмент под названием pip-tools, который помогает мне в этом. Он предоставляет набор инструментов командной строки, которые помогают управлять вашими зависимостями. Он автоматически генерирует requirements.txt, который закрепляет не только ваши зависимости, но и все ваше дерево зависимостей, которое включает в себя зависимости ваших зависимостей.

В сценариях, где вам нужно обновить определенные пакеты из вашего списка зависимостей, это может стать проблемой, если вы использовали «заморозку пипсов», потому что вы не видите, какие зависимости принадлежат каким пакетам. Следовательно, обновление конкретной зависимости становится громоздким. К счастью, с помощью pip-tools эта проблема решается. Автоматически закрепляя пакеты на основе указанных вами зависимостей, pip-tools интеллектуально решает, какие пакеты требуют обновления, упрощая процесс обновления определенных зависимостей. В качестве бонуса вы также точно знаете, какой пакет пришел из какой зависимости, потому что он помечает их комментариями в файле requirements.txt.

Чтобы быть особенно осторожным, неплохо также сделать резервную копию исходных файлов зависимостей! Храните копию в своей файловой системе, в папке, управляемой Git, в папке S3, на FTP, SFTP — где угодно, но всегда под рукой. Были случаи, когда относительно небольшой пакет, не указанный в списке, ломал большое количество пакетов в npm. Pip услужливо предоставляет инструмент для загрузки всех необходимых зависимостей в виде исходных файлов, читайте больше, запустив pip help download.

Вот так, ребята! Надеюсь моя статья поможет вам в вашем бизнесе

Спасибо, что прочитали это! Ждем ваших комментариев и предложений 😎✌