10 Основних помилок, що здійснюються django-розробниками

10 Основних помилок, що здійснюються django-розробниками

Django - безкоштовний мережевий open source Python-фреймворк, що допомагає вирішувати поширені в розробці проблеми. Він дозволяє створювати гнучкі, добре структуровані програми. В Django вже з коробки є багато сучасних можливостей. Наприклад, для мене такі фічі, як Admin, інструмент Object Relational Mapping (ORM), Routing і Templating, роблять Django першим кандидатом при виборі інструментарію для розробки. Створення програми вимагає багато сил, і, насолоджуючись своєю справою, як і будь-який розробник, я хочу витрачати якомога менше часу на рутинні завдання. Django сильно в цьому допомагає, чи не змушуючи жертвувати гнучкістю додатки.

Кілер-фіча Django - потужний конфігурується адмінських інтерфейс, який автоматично (автомагіческі?) Генерується на основі схеми вашої моделі і моделей адмінки. Відчуваєш себе прямо-таки чарівником. За допомогою інтерфейсу Admin користувач може конфігурувати багато речей, в їх числі - список управління доступом (access control list, ACL), дозволу і дії на рівні рядків (row-level), фільтри, порядки сортування (orders), віджети, форми, додаткові URL-хелпери і багато іншого. Я вважаю, що админка потрібна кожному з додатком. Це лише питання часу, коли така панель знадобиться вашого основного додатком. В Django вона створюється швидко і зручно.

Також в Django є потужна ORM, з коробки працює з усіма головними базами даних. Вона «лінива»: на відміну від інших ORM, звертається до БД тільки в міру необхідності. У ній є підтримка основних SQL-інструкцій (і функцій), які ви можете використовувати зі свого вихідного Python-коду поряд з усіма іншими можливостями мови.
В Django дуже гнучкий і потужний шаблонизатор (templating engine). Доступні багато стандартні фільтри і мітки (tags), також можна створювати свої власні. Django підтримує інші движки як власні шаблони, надає API для легкої інтеграції з іншими двигунами за допомогою стандартних shortcut-функцій для обробки шаблонів.

Фреймворк має і багато інших важливих можливостей на зразок URL-роутера, який парсит вхідні запити і генерує нові URL на основі схеми роутінга. В цілому Django приємний в роботі, і, коли вам знадобиться допомога, просто почитайте документацію.

Помилка № 1. Використання для проектних залежностей глобального оточення Python

Не використовуйте глобальне оточення Python для залежностей вашого проекту, тому що це може привести до виникнення конфліктів залежностей. Python не вміє працювати з декількома версіями пакетів одночасно. Це стане проблемою, якщо різним проектам потрібні різні, несумісні версії одного пакета.

Зазвичай таку помилку допускають новачки в Python- і Django-розробці, які не знають про особливості ізоляції оточення Python.

Є багато способів ізолювати оточення, найбільш часто зустрічаються такі:

  • virtualenv. пакет Python, що генерує папку з оточенням. Містить скрипт для (де) активації оточення і управління встановленими в ньому пакетами. Це мій улюблений і найпростіший метод. Зазвичай я створюю оточення ближче до папки проекту.
  • virtualenvwrapper. пакет Python, глобально встановлює набір інструментів для створення / видалення / активації і т. д. віртуальних оточень і надає доступ до цього набору. Все оточення зберігаються в одній папці (її можна переписати за допомогою змінної WORKON_HOME). Я не бачу переваг у використанні virtualenvwrapper замість virtualenv.
  • Віртуальні машини. немає кращої ізоляції, ніж ціла віртуальна машина, виділена під вашу програму. Є маса доступних інструментів, наприклад VirtualBox (безкоштовний), VMware. Parallels і Proxmox (мій фаворит, є безкоштовна версія). У поєднанні з інструментом автоматизації віртуальних машин на зразок Vagrant це може виявитися дуже потужним рішенням.
  • Контейнери. в останні роки я майже в кожному проекті використовую Docker. особливо в нових проектах, починаємо з нуля. Docker - неймовірний інструмент з безліччю можливостей. Для його автоматизації доступна купа сторонніх інструментів. В Docker є кешування рівнів (layer caching), що дозволяє вкрай швидко пересоздавать контейнери. У них я використовую глобальне оточення Python, тому що кожен контейнер має власну файлову систему і проекти ізолюються на високому рівні. Docker дозволяє новим членам команди швидше починати роботу над проектом, особливо якщо у них є досвід роботи з цією технологією.

Помилка № 2. Відсутність прив'язки залежностей в файлі requirements.txt

Кожен новий проект Python повинен починатися з файлу requirements.txt і нового ізольованого оточення. Зазвичай ви за допомогою pip / easy_install встановлюєте усі пакети, не забуваючи про requirements.txt. Зазвичай простіше (можливо. Правильніше) розгортати проекти на серверах або на машинах членів команди.

Також важливо в файлі requirements.txt виконувати прив'язку (pin) конкретних версій ваших залежностей. Зазвичай різні версії пакету надають різні модулі, функції і параметри функцій. Навіть в молодших версіях зміни залежностей можуть виявитися такими, що це зламає ваш пакет. Це дуже серйозна проблема, якщо у вас живий проект і ви плануєте регулярно його розгортати, так як без системи управління версіями ваша складальна система завжди буде встановлювати останню доступну версію пакету.

У production завжди виконуйте прив'язку пакетів! Я для цього використовую дуже хороший інструмент pip-tools. Він надає набір команд, які допомагають керувати залежностями. Інструмент автоматично генерує requirements.txt. в якому прив'язані не просто ваші залежності, а взагалі все дерево, т. е. і залежно ваших залежностей.

Якщо бути ще більш обережним, то можна робити бекап вихідних файлів ваших залежностей. Зберігайте копію в своїй файлової системи, Git-папці, S3-папці, FTP, SFTP - де завгодно, лише б під рукою. Бувають ситуації, коли виключення зі списку відносно невеликого пакета ламає велика кількість пакетів в npm. Pip дозволяє завантажувати всі необхідні залежності у вигляді вихідних файлів. Почитайте про це докладніше, виконавши команду pip help download.

Помилка № 3. Використання старомодних Python-функцій замість уявлень-класів (Class-based Views)

Іноді доцільно використовувати у файлі додатки views.py маленькі Python-функції, особливо для тестових або утилітарних уявлень. Але зазвичай в додатках потрібно використовувати уявлення на основі класів (CBV).

CBV - це уявлення загального призначення, що надають абстрактні класи, що реалізують поширені завдання веб-розробки. CBV створені професіоналами і покривають більшість затребуваних моделей поведінки. У них є прекрасно структурований API, і CBV подарують вам можливість насолоджуватися всіма перевагами ООП. Ваш код буде чистіше і Новомосковскбельнее. Забудьте про труднощі використання стандартних функцій уявлення (view functions) Django для створення списків, CRUD-операцій, обробки форм і т. Д. Можна просто розширювати відповідний CBV під ваше уявлення і перевизначати (override) функції або властивості класу, конфігурують поведінку уявлення (зазвичай функція повертає властивість, і ви можете додати в неї будь-яку логіку, яка здатна перетворити ваш код в спагетті, якщо замість CBV ви втечете до функцій уявлення).

Я створив пакет Django Template Names. який стандартизує імена шаблонів для ваших уявлень на основі імені додатки і імені класу уявлення. Я користуюся ним щодня і економлю купу часу при виборі імен. Просто вставте миксин в свій CBV - class Detail (TemplateNames, DetailView): - і він почне працювати! Звичайно, можете перевизначити мої функції і додати мобільні адаптивні шаблони, інші шаблони для user-agent'ов або що-небудь ще.

Помилка № 4. Написання «товстих» (fat) уявлень і «тонких» (skinny) моделей

Якщо у вас логіка додатка перенесена з моделі в уявлення, це означає, що в уявленнях знаходиться код, який належить моделі. Тобто уявлення стають «товстими», а модель - «тонкої».

А потрібно писати «товсті» моделі і «тонкі» уявлення.

Розбийте логіку по маленьким методам в моделі. Це дозволить використовувати їх багаторазово і з численних джерел (адмінських призначений для користувача інтерфейс, призначений для користувача інтерфейс фронтенда, кінцеві точки API, численні уявлення). Це займе всього кілька рядків коду, і вам не доведеться копіпаст купу рядків. Коли наступного разу будете писати функціональність відправлення листа користувачу, розширте модель за допомогою email-функції, а не пишіть логіку в контролері.

Помилка № 5. Величезний, неповороткий файл настройок

Навіть в новому файлі налаштувань Django-проекту цих налаштувань міститься безліч. А в реальних проектах файл розростається до 700+ рядків, які важко супроводжувати, особливо коли оточенням розробки, продакшена і стейджінга потрібні різні конфігурації.

Ось приклад мінімальній конфігурації:

Помилка № 6. Додаток все-в-одному, погана структура програми та некоректне розміщення ресурсів

Будь Django-проект складається з декількох додатків. У термінології Django додаток - це Python-проект, що містить як мінімум файли __init__.py і models.py. В останніх версіях Django models.py більше не потрібен, достатньо тільки __init__.py.

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

Рекомендується назвати папку проекту project і покласти додатки в project / apps /. Потім покласти все залежності додатків у власні папки.

  • Статичні файли: project / apps / appname / static / appname /
  • Мітки шаблону: project / apps / appname / templatetags / appname.py
  • Файли шаблону: project / apps / appname / templates / appname /

Завжди додавайте імена додатків у вигляді префіксів в назви підпапок, тому що все статичні папки об'єднуються в одну. І якщо два або більше додатків мають файл js / core.js. то останнім додаток в settings.INSTALLED_APPLICATIONS перевизначити всі попередні. Одного разу я зіткнувся з таким багом в своєму проекті і витратив близько шести годин на налагодження, поки не зрозумів, що інший розробник перевизначив мій static / admin / js / core.js. тому члени команди реалізували кастомную адмінській SPA-панель і дали своїх файлів такі ж імена.

Ось приклад структури для портального додатки, що містить багато ресурсів і Python-модулів.

Звичайно, реальний проект буде складніше, але така структура спрощує і робить більш прозорими багато аспектів.

Помилка № 7. STATICFILES_DIRS і STATIC_ROOT бентежать новачків в Django-розробці

У режимі розробки - python manage.py runserver - Django шукає статичні файли за допомогою настройки STATICFILES_FINDERS. За замовчуванням він намагається знайти запитаний файл в папках, перерахованих в STATICFILES_DIRS. Якщо не знаходить, то шукає за допомогою django.contrib.staticfiles.finders.AppDirectoriesFinder. яка перевіряє папку static кожного встановленого в проекті програми. Така схема дозволяє писати багаторазово використовувані додатки, що поставляються з власними статичними файлами.

У production ви роздає статичні дані за допомогою окремого веб-сервера, наприклад nginx. Він нічого не знає про структуру додатків проекту Django або про те, за якими папок розподілені ваші статичні файли. На щастя, Django надає нам команду управління збором статичних даних (collect static management command) - python manage.py collectstatic. яка проходить по STATICFILES_FINDERS і копіює все статичні файли з папок static додатків, а також з папок, перерахованих в STATICFILES_DIRS. в задану вами в STATIC_ROOT директорію. Це дозволяє вирішувати (resolution) ресурси у вигляді статичних даних за допомогою тієї ж логіки, що і у Django-сервера в режимі розробки, і збирати в одному місці для веб-сервера все статичні файли.

Не забудьте виконати collectstatic в вашому production-оточенні!

Помилка № 8. Використання в production STATICFILES_STORAGE за замовчуванням і завантажувачів Django-шаблонів

Для цього можна використовувати ManifestStaticFilesStorage як STATICFILES_STORAGE (будьте обережні, змішування включається тільки в режимі DEBUG = false) і виконати команду collectstatic. Це призведе до зниження кількості запитів ресурсів у вашого production-сайту і зробить його отрисовку набагато швидше.

Кльова фіча Django - закеширувалася завантажувач шаблону. Він не перезавантажується і парсит файли шаблону при кожній його відображенні. Парсинг шаблону - дуже дорога операція, вона вимагає багато обчислювальних ресурсів. За замовчуванням Django-шаблони Парс при кожному запиті, а це погано, особливо в production, де за короткий проміжок часу можуть оброблятися тисячі запитів.

У розділі конфігурації cached.Loader можна знайти хороший приклад і подробиці вирішення проблеми. Не використовуйте завантажувач в режимі розробки, тому що він не перезавантажує отпарсенние шаблони з файлової системи. Вам знадобиться перезапускати свій проект, використовуючи python manage.py startapp. при кожній зміні шаблону. При розробці це може дратувати, зате ідеально для production-оточення.

Помилка № 9. Чистий Python для утиліт або скриптів

У Django є відмінна фіча - команди управління. Використовуйте їх замість винаходу велосипеда в вигляді написання скриптів на чистому Python для утиліт вашого проекту.

Також зверніть увагу на пакет Django Extensions. представляє собою колекцію кастомних розширень для Django. Можливо, хтось уже реалізував ваші команди! Існує багато поширених цільових команд.

Помилка № 10. велосипедостроєнія

Для Django і Python є тисячі готових рішень. Зверніться до пошуковиків, перш ніж писати щось, що зовсім не унікальна. Ймовірно, вже є відповідне рішення.

Не треба ускладнювати. Спочатку - гугл! Встановіть знайдений якісний пакет, налаштуйте, розширте і інтегруйте в свій проект. І якщо є можливість, внесіть свій внесок в open source.

Ось вам для початку список моїх власних пакетів для Django:

  • Django Macros URL. за допомогою макросів полегшує написання (і читання) URL-патернів в Django-додатках.
  • Django Templates Names. маленький миксин, допомагає легко стандартизувати імена ваших CBV-шаблонів.
  • Django Split Settings. дозволяє розподілити Django-настройки по декількох файлах і директоріях. Легко переопределяет і модифікує настройки. Використовує підстановки (wildcards) в шляхах файлів і позначає файли налаштувань як опціональні.

Do not repeat yourself (DRY)!

Я прихильник DRY-концепції, тому створив Django skeleton - зручний інструмент з рядом приємних функцій вже з коробки:

  • Docker-образи для розробки / production, керовані docker-compose, що дозволяє легко оркестріровать списком контейнерів.
  • Простий Fabric-скрипт для розгортання в production.
  • Конфігурація для пакета Django Split Settings з настройками бази і локальних джерел.
  • Інтегрований в проект Webpack - при виконанні команди collectstatic Django збере тільки папку dist.
  • Сконфігуровані всі основні Django-настройки та фічі начебто кешіруемих в production Django-шаблонів, хешировать статичних файлів, інтегрованого тулбару для налагодження, журналирования і т. Д.

Це готовий до використання Django-скелет для вашого наступного проекту, створюваного з нуля. Сподіваюся, він заощадить вам купу часу. Webpack має мінімальну базову конфігурацію, але також в нього за допомогою SASS встановлені заздалегідь сконфігуровані для обробки файли .scss.