قم بتحسين مشروع Django الخاص بك باستخدام أفضل الممارسات هذه

يعد Django إطار عمل قويًا ومفتوح المصدر وقائم على لغة Python لبناء تطبيقات الويب. ازدادت شعبيتها خلال العامين الماضيين ، وهي بالفعل ناضجة ومستخدمة على نطاق واسع مع وجود مجتمع كبير وراءها.

من بين الأطر الأخرى المستندة إلى Python لإنشاء تطبيقات الويب (مثل Flask و Pyramid) ، فإن Django هو الأكثر شعبية إلى حد بعيد. وهو يدعم كلا من Python الإصدار 2.7 و Python 3.6. ولكن في وقت كتابة هذه المقالة ، لا يزال Python 2.7 هو الإصدار الذي يسهل الوصول إليه من حيث المجتمع وحزم الجهات الخارجية والوثائق عبر الإنترنت. إن Django آمن عند استخدامه بشكل صحيح ، ويوفر أبعادًا عالية من المرونة. إنها الطريقة المثلى عند تطوير تطبيقات من جانب الخادم باستخدام Python.

بصفتي مطورًا متمرسًا في Python و Django ، سأشارك معك بعض أفضل الممارسات لإعداد Django التي تعلمتها وجمعتها على مر السنين. سواء كان لديك عدد قليل من مشاريع Django تحت حزامك ، أو كنت على وشك بدء مشروعك الأول من الصفر ، فإن أفضل الممارسات الموضحة هنا قد تساعدك على إنشاء تطبيقات أفضل في المستقبل.

لقد كتبت هذا المقال من عقلية عملية للغاية بحيث يمكنك إضافة بعض الأدوات إلى صندوق أدوات التطوير الخاص بك على الفور. يمكنك أيضًا إنشاء نموذج متقدم مخصص لـ Django لمشاريعك القادمة.

لغرض هذه المقالة ، أفترض أنك تستخدم جهاز Linux Ubuntu. في جميع أنحاء المقالة ، تبدأ بعض أسطر الكود $بعلامة. تستخدم هذه للتأكيد على أنه يجب إدخال هذا الخط في الجهاز. تأكد من نسخ الخط دون أن $علامة.

بيئة افتراضية

أثناء تطوير التطبيقات المستندة إلى Python ، يعد استخدام حزم الجهات الخارجية أمرًا مستمرًا. يتم تحديث هذه الحزم في كثير من الأحيان ، لذلك من الضروري إبقائها منظمة. عند تطوير المزيد والمزيد من المشاريع على نفس الجهاز المحلي ، يكون من الصعب تتبع الإصدار الحالي من كل حزمة. من المستحيل استخدام إصدارات مختلفة من نفس الحزمة لمشاريع مختلفة. علاوة على ذلك ، قد يؤدي تحديث حزمة في مشروع ما إلى تعطيل الوظائف في مشروع آخر ، والعكس صحيح.

هذا هو المكان الذي تكون فيه Python Virtual Environment سهلة الاستخدام. لتثبيت البيئة الافتراضية ، استخدم:

$ apt-get update $ apt-get install python-pip python-dev build-essential $ export LC_ALL="en_US.UTF-8" # might be necessary in case you get an error from the next line $ pip install --upgrade pip $ pip install --upgrade virtualenv $ mkdir ~/.virtualenvs $ pip install virtualenvwrapper $ export WORKON_HOME=~/.virtualenvs $ nano ~/.bashrc

أضف هذا السطر إلى نهاية الملف:

. /usr/local/bin/virtualenvwrapper.sh

ثم نفذ:

$ . .bashrc

بعد التثبيت ، أنشئ بيئة افتراضية جديدة لمشروعك عن طريق كتابة:

$ mkvirtualenv project_name

أثناء تواجدك في سياق بيئتك الافتراضية ، ستلاحظ إضافة بادئة إلى المحطة ، مثل:

(project_name) [email protected]:~$

لإلغاء تنشيط (الخروج) من البيئة الافتراضية والعودة إلى سياق Python الرئيسي لجهازك المحلي ، استخدم:

$ deactivate

لتفعيل (بدء) سياق البيئة الافتراضية ، استخدم:

$ workon project_name

لسرد البيئات الافتراضية الموجودة في جهازك المحلي ، استخدم:

$ lsvirtualenv

يتيح لك الاحتفاظ بالاعتمادات (الحزم) الخاصة بالمشروع في بيئة افتراضية على جهازك الاحتفاظ بها في بيئة معزولة. أنت تستخدمها فقط لمشروع واحد (أو متعدد). عند إنشاء بيئة افتراضية جديدة ، فإنك تبدأ بيئة جديدة بدون حزم مثبتة فيها. ثم يمكنك استخدام ، على سبيل المثال:

(project_name) $ pip install Django

لتثبيت Django في بيئتك الافتراضية ، أو:

(project_name) $ pip install Django==1.11

لتثبيت الإصدار 1.11 من Django يمكن الوصول إليه فقط من داخل البيئة.

لن يتمكن مترجم Python الرئيسي ولا البيئات الافتراضية الأخرى على جهازك من الوصول إلى حزمة Django الجديدة التي قمت بتثبيتها للتو.

من أجل استخدام الأمر runserver باستخدام بيئتك الافتراضية ، بينما في سياق البيئة الافتراضية ، استخدم:

(project_name) $ cd /path/to/django/project (project_name) $ ./manage.py runserver

وبالمثل ، عند إدخال مترجم Python من داخل البيئة الافتراضية ، اكتب:

(project_name) $ python

سيكون لديه حق الوصول إلى الحزم التي قمت بتثبيتها بالفعل داخل البيئة.

المتطلبات

المتطلبات هي قائمة حزم Python (التبعيات) التي يستخدمها مشروعك أثناء تشغيله ، بما في ذلك إصدار كل حزمة. فيما يلي مثال requirements.txtلملف:

dicttoxml==1.7.4 Django==1.11.2 h5py==2.7.0 matplotlib==2.0.2 numpy==1.13.0 Pillow==4.1.1 psycopg2==2.7.1 pyparsing==2.2.0 python-dateutil==2.6.0 pytz==2017.2 six==1.10.0 xmltodict==0.11.0

يعد تحديث ملفك requirements.txtأمرًا ضروريًا للتعاون بشكل صحيح مع المطورين الآخرين. من المهم أيضًا الحفاظ على تكوين بيئة الإنتاج بشكل صحيح. يمكّنك هذا الملف ، عند تضمينه في مستودع التعليمات البرمجية الخاص بك ، من تحديث جميع الحزم المثبتة في بيئتك الافتراضية عن طريق تنفيذ سطر واحد في الجهاز. ثم يمكنك الحصول على مطورين جدد وتشغيلهم في لمح البصر.

من أجل إنشاء واحدة جديدة requirements.txtأو لتحديث واحدة موجودة ، استخدم من داخل بيئتك الافتراضية:

(project_name) $ pip freeze > requirements.txt

لراحتك ، تأكد من تنفيذ هذا الأمر في مجلد يتم تعقبه بواسطة مستودع Git الخاص بك. يسمح هذا لمثيلات أخرى من الكود بالوصول إلى requirements.txtالملف أيضًا.

إذا انضم مطور جديد إلى الفريق ، أو إذا كنت ترغب في تكوين بيئة جديدة باستخدام نفس الحزم المدرجة في requirements.txtالملف ، فنفذ في سياق البيئة الافتراضية:

(project_name) $ cd /path/to/requirements/file (project_name) $ pip install -r requirements.txt

سيتم تثبيت جميع المتطلبات المدرجة في الملف على الفور في بيئتك الافتراضية. سيتم تحديث الإصدارات الأقدم وسيتم تخفيض الإصدارات الأحدث لتلائم قائمة requirements.txt. كن حذرًا - فقد تكون هناك اختلافات بين البيئات التي لا تزال ترغب في احترامها.

I highly recommend integrating these commands to your work flow. Update the requirements.txt file before pushing code to the repository and install requirements.txt file after pulling code from the repository.

Better settings.py configuration

Django comes out-of-the-box with a very basic yet useful settings.py file. This defines the main and most useful configurations for your project. The settings.py file is very straightforward. But sometimes, as a developer working on a team, or when setting up a production environment, you need more than one basic settings.py file.

Multiple settings files allow you to easily define tailor-made configurations for each environment separately like:

ALLOWED_HOSTS # for production environment DEBUG DATABASES # for different developers on the same team

Let me introduce you to an extended approach for configuring your settings.py file. It allows you to maintain different versions and use the one you want at any given time and in any environment.

First, navigate to your settings.py file path:

(project_name) $ cd /path/to/settings/file

Then create a new module called settings (module is a folder containing an __init__.py file):

(project_name) $ mkdir settings

Now, rename your settings.py file to base.py and place it inside the new module you created:

(project_name) $ mv settings.py settings/base.py

For this example, I assume that you want to configure one settings file for your development environment and one for your production environment. Different developers on the same team can use the exact same approach for defining different settings files.

For your development environment create:

(project_name) $ nano settings/development.py

Then type:

from .base import * DEBUG = True

and save the file by hitting Ctrl + O, Enter and then Ctrl + X.

For your production environment create:

(project_name) $ nano settings/production.py

and type:

from .base import * DEBUG = False ALLOWED_HOSTS = [‘app.project_name.com’, ]

Now, whenever you want to add or update the settings of a specific environment, you can easily do it in its own settings file.

You might be wondering — how does Django know which settings file to load on each environment? That’s what the __init__.py file is used for. When Django looks for the settings.py it used to load when running the server, for example, it now finds a settings module rather than a settings.py file. But as long as it’s a module containing an __init__.py file, as far as Django is concerned, it’s the exact same thing. Django will load the __init__.py file and execute whatever is written in it.

Therefore, we need to define which settings file we want to load inside the __init__.py file by executing:

(project_name) $ settings/__init__.py

and then, for a production environment, for example, by typing:

from .production import *

This way, Django will load all the base.py and production.py settings every time it starts. Magic?

Now, the only configuration left is to keep the __init__.py in your .gitignore file so it will not be included in pushes and pulls. Once you set up a new environment, don’t forget to create a new __init__.py file inside the settings module. Then import the settings file required exactly like we did before.

In this article we’ve covered three best practices for better setting up your Django project:

  • Working inside a virtual environment
  • Keeping the requirements.txt file up to date and using it continuously in your work flow
  • Setting up a better project settings array

Have you followed these best practices in your last project? Do you have any insights to share? Comments are highly appreciated.

هل وجدت هذا مفيد؟ إذا كان الأمر كذلك ، من فضلك أعطني بعض التصفيق حتى يرى المزيد من الناس المقال.

هذا هو الجزء الأول من السلسلة حول أفضل الممارسات لتطوير Django. تابعني للحصول على تحديث فوري بمجرد توفر الأجزاء التالية.

اعثر على المزيد من النصائح الرائعة لأصحاب المشاريع التكنولوجية في CodingStartups.