Email: office@yourdomain.com
Phone:: +44 20 7240 9319
back to top

Blog

Ошибки разработки на Django в 2014 году

Это мой первый перевод статьи Django Development Mistakes In 2014

Пока стремительно приближается 2015 год, я взял некоторое время, чтобы подумать над тем, что я бы сделал по другому с точки зрения разработки в 2014 году. В моей предыдущей статье 11 Things I wish I knew about Django Before Starting My Companyя начинал список. Сейчас пришло время его дополнить.

1. Используйте Postgres как основное хранилище данных

Я знаю, что в предыдущей статье я пропагандировал использование MongoDB в качестве основной базы данных, но спустя полтора года использования, я больше не хочу этого делать из-за целого ряда причин:

  • На момент Django 1.7,  все еще нет поддержки для MongoDB через Django ORM. Вам необходимо использовать Mongoengine/PyMongo. Оба этих проекта замечательные, но поскольку Django не поддерживает MongoDB, вы не можете использовать Django admin —это действительно хреново и одна из причин, почему я прекратил использовать MongoDB в качестве основного хранилища данных.
  • По состоянию на 18.12.2014, Postgres сейчас поддерживает формат JSONB, что означает возможность сохранения “документов” в Postgres и запуска похожих запросов (с возможностью их индексации) как и в MongoDB, без потери производительности.
  • Большинство сторонних библиотек бесполезны, потому что они предполагают, что вы используете Django ORM. Это делает использование экосистемы Django практически невозможным. Экосистема Django восхитительна и становиться лучше каждый день, а здесь такой облом.

Если вы разрабатываете на OSX, то не тратьте ваше время на сборку Postgres из исходных кодов, а используйте Postgres App — это сэкономит много времени.

2. Создавайте структуру для unit тестирования, что позволит облегчить написание unit тестов

Есть множество статей, как положительных, так и отрицательных о разработке через тестирование (TDD) и Django. Я не принимаю никакую сторону в этом сражении, но одно, что я пытаюсь делать в каждом проекте – настраиваю феймворк так, чтобы написание unit-тестов простым и веселым (да, веселым). Каждый проект, с которым я работаю, имеет класс, который действует как примесь (mixin) для всех TestCases. Каждый unit-тест (класс) потом наследуется из этой примеси и имеет экземпляр основанный на методах для создания данных для каждого теста. Случайные данные генерируются с помощью замечательного проекта django_faker. Данные создаются в методе setUp() и удаляются в tearDown(). Если вы заинтересовались, то пожалуйста прочтите мою статью о unit-тестировании в Django.

3. Создавайте RESTful интерфейсы с использованием Django Tastypie

С распространением таких клиентских MVC решений как Ember.jsBackbone.js, и Angular.js, теперь гораздо сильнее требуется поддержка RESTful интерфейса в вашем web-приложении. Django имеет два прекрасных фреймворка , которые могут быть использованы для построения REST APIs: django-rest-framework и django-tastypie. Хотя у меня и есть чувство, что django-rest-framework более популярный, но я по прежнему большой фанат django-tastypie. Он выглядит более простым и существует немного дольше. С учетом сказанного, если вы создаете публичный API — используйте строго django-rest-framework, так как он предоставляет возможность построить для вас документацию вашего API абсолютно бесплатно. Если вам нужна помощь, чтобы начать работать с django-tastypie, то изучите эту статью, где я описал настройку Django проекта с использованием этой библиотеки.

4. Используйте атрибут help_text в полях моделей Django как возможность документирования форм

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

5. Не используйте параметры запросов в клиентских URLs, используйте модуль Djangos URL для задания строгих значений

Это может быть очевидным для опытных веб-разработчиков, но когда это возможно – я не используют параметры HTTP запроса в ссылках — я избегаю это используя url со значениями. Мой аргумент использования модуля работы URL в Django это обеспечивать соблюдение значений параметров.

Качестве примера есть URL https://www.example.com/user?id=20, который может быть переписан следующим образом https://www.example.com/user/20/

Теперь вам можно будет писать меньше проверок на типы в ваших контроллерах, потому что проверку можно сделать в модуле Django URL который возвратит HTTP 404 в случае, если будет передано любое не цифровое значение, которые не подходит к полю “id”. Я понимаю, что это нельзя применять постоянно, но каждый раз, когда я могу использовать это, я придерживаюсь этого шаблона разработки.

6. Используйте Django ORM для обеспечения соблюдения значений в базе данных:

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

  • Если поле не должно быть никогда null, то не устанавливайте атрибут null=True
  • Используйте unique_together для соблюдения уникальных значений и предотвращения дублей.
  • Используйте атрибут unique когда это возможно.
  • Задавайте полям max_length соответственно значениям.

В принципе, проведите разумное время на правильный дизайн моделей вашей базы данных и используйте Django ORM максимально возможно для задания данных! Сделайте невозможным сохранять неверные данные!

7. Используйте библиотеки django_model_utils и django_extensions в каждом проекте

Django-extensions – сторонняя библиотека, которая обеспечивает ряд функциональных возможностей: выводит настройки, shell_plus, экспортирует скрипты, шифрование и так далее. Я замечаю, что использую все больше и больше возможностей в повседневной работе.

Django-model-utils содержит кучу полезных функций, которые сейчас не доступны в Django ORM (или реализованы иначе): TimeStampField, MonitorField, Choices, и так далее.

До того как изобретать заново колесо, убедитесь, что проверили оба этих проекта.

8. Используйте Sentry для мониторинга ошибок как на клиентской, так и на серверной стороне

Sentry это open source решение для мониторинга, написанное с применением фреймворка Django. Вы можете либо заплатить за подписку на getsentry.com или разместить сервис самостоятельно у себя. Sentry является незаменимым инструментом для диагностики как клиентского, так и серверного кода на ошибки. Вы можете отслеживать все виды полезной информации, такой как:

  • количество раз появления ошибки в прошлом
  • информация о браузере
  • время и место появления ошибки
  • стек вызов при ошибке 500
  • ответы клиенту 404 и 403
  • Переменные со значением undefined в клиентском javascript

Тарифные планы начинаются от $24/месяц — и это, безусловно, деньги потраченные не зря.

9. Используйте djangodebugtoolbar для отладки и оптимизации вашего сайта

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

10. Используйте Django Custom User Model с самого первого коммита

Django 1.6 представил custom user models и я категорически рекомендую начинать с этого, а не использовать встроенную в Django модель пользователя. Добавление полей в модель пользователя здесь более интуитивное и лучше альтернативных методов, которые расширяют модель с помощью других моделей используя поле OneToOne. Если вы использовали Django некоторое время, то возможно обнаружили, что поля email и имени пользователя стандартной модели пользователя ограничены в 30 символов и этого бывает не достаточно. Если вы начнете проект с custom user model, то решите все эти вопросы и будете добавлять новые поля и изменять их с помощью миграций. Произвести миграцию встроенной модели пользователя в модель custom user возможно, но совсем не весело – поверьте мне на слово.

11. Рассмотрите использование альтернативных решений для djangoadmin

Django admin это клево, но дизайн уже немного устарел. Если вы разрабатываете сайт для заказчика и он платит вам за это, то есть ряд альтернативных более профессиональных и очень простых в установке решений. Два моих предпочитаемых решения это django-grappelli и django-suit. Больше решений можно найти в этом списке.