أهم 10 أخطاء ارتكبها مطورو Django

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

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

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

تمتلك Django إدارة ORM قوية تعمل مع جميع قواعد البيانات الرئيسية خارج الصندوق. نظرًا لأنه كسول ، فإنه يصل إلى قاعدة البيانات الخاصة بك فقط عندما تحتاج إليها ، على عكس ORMs الأخرى. وهو يدعم جميع تعليمات (ووظائف SQL) الرئيسية التي يمكنك استخدامها من شفرة مصدر Python الخاصة بك وتشعر بالراحة بسبب ميزات Python.

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

لدى Django الكثير من الميزات الكبيرة الأخرى مثل موجه URL الذي يمكنه تحليل الطلبات الواردة وإنشاء عناوين URL جديدة من مخطط جهاز التوجيه. بشكل عام ، يعد إطار عمل Django تجربة ممتعة ، وكلما احتجت إلى مساعدة ، ما عليك سوى قراءة الوثائق.

الخطأ رقم 1: استخدام بيئة Python للنظام العالمي لتبعيات المشروع

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

عادة ما يتم ارتكاب هذا الخطأ بواسطة مطوري Python و Django الجدد الذين لا يعرفون ميزات عزل بيئة Python.

هناك العديد من الطرق لعزل بيئتك ، ولكن أكثر الطرق شيوعًا هي:

• Virtualenv: حزمة Python التي تنشئ مجلد بيئة Python وتحتوي على نصوص لتفعيل البيئة وإدارة حزم Python المثبتة في البيئة. هذه هي الطريقة المفضلة لدي لأنها أبسط طريقة للقيام بالمهمة. عادة ، أقوم بإنشاء بيئة قريبة من مجلد المشروع.
• Virtualenvwrapper: حزمة Python يتم تثبيتها عالميًا وتوفر مجموعة أدوات لإنشاء / حذف / تنشيط / إلخ. البيئات الافتراضية. يتم تخزين جميع البيئات الافتراضية في مجلد واحد (والذي يمكن تجاوزه من خلال متغير البيئة WORKON_HOME). لا أرى أي مزايا لاستخدام virtualenvwrapper بدلاً من virtualenv .
• الأجهزة الافتراضية (VM): ليس هناك عزلة أكبر من آلة افتراضية كاملة مخصصة لتطبيقك. هناك الكثير من الأدوات للاختيار من بينها ، بما في ذلك VirtualBox (مجاني) و VMware و Parallels و Proxmox (المفضل لدي ، ولديه إصدار مجاني). إلى جانب أداة أتمتة VM مثل Vagrant ، يمكن أن يكون هذا حلاً قويًا للغاية.
• الحاويات: في السنوات القليلة الماضية ، كنت أستخدم Docker في كل مشروع تقريبًا ، خاصة في كل مشروع جديد أبدأ من الصفر. Docker هي أداة رائعة توفر الكثير من الميزات ولديها الكثير من أدوات الطرف الثالث لأتمتة الحاويات. يحتوي على ميزة التخزين المؤقت للطبقة والتي تجعل إعادة بناء الحاويات الخاصة بك سريعة للغاية. في الحاويات ، أستخدم بيئة Python للنظام العالمي ، لأن كل حاوية لها نظام ملفات خاص بها ومشاريع معزولة على مستوى عالٍ. يسمح Docker لأعضاء الفريق الجدد ببدء العمل في المشروع بشكل أسرع ، خاصة إذا كانت لديهم خبرة Docker.

إذا سألتني ، فأنا أفضل حزمة virtualenv Python وحاويات Docker لعزل تبعية المشروع وإدارتها.

الخطأ الثاني: عدم تثبيت تبعيات المشروع في ملف requirements.txt

يجب أن يبدأ كل مشروع Python جديد بملف requirements.txt وبيئة معزولة جديدة. عادةً ما تقوم بتثبيت جميع الحزم من خلال pip/easy_install ولكن لا تنس أبدًا إضافتها إلى ملف requirements.txt أيضًا. هذا يسهل (من الممكن أن يكون أكثر ملاءمة) لنشر مشروعك على الخوادم ، أو أن يقوم أحد أعضاء الفريق بتمهيد المشروع على أجهزتهم الخاصة.

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

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

في بعض الأحيان ، تريد تحديث بعض الحزم فقط من قائمة التبعيات الخاصة بك (على سبيل المثال ، فقط Django / Flask / أي إطار عمل أو أداة مساعدة) ، إذا استخدمت "pip freeze" ، فأنت لا تعرف التبعيات الخاصة بالحزم ، وبالتالي أنت لا يمكن ترقية التبعية. ومع ذلك ، باستخدام أدوات النقطة ، يقوم تلقائيًا بتثبيت الحزم بناءً على التبعية التي قمت بتثبيتها ، لذلك يقوم تلقائيًا بتحديد الحزم التي تحتاج إلى تحديث. كمكافأة ، أنت تعرف أيضًا بالضبط الحزمة التي جاءت من أي تبعية بسبب كيفية تمييزها بالتعليقات في ملف requirements.txt .

لمزيد من الحذر ، من الجيد عمل نسخة احتياطية من ملفات مصدر التبعية أيضًا! احتفظ بنسخة في نظام الملفات لديك ، أو مجلد مُدار بواسطة Git ، أو مجلد S3 ، أو FTP ، أو SFTP - في أي مكان ، ولكن في متناول اليد. كانت هناك حالات حيث كانت حزمة صغيرة نسبيًا غير مدرجة تكسر عددًا كبيرًا من الحزم على npm. يوفر Pip أداة مفيدة لتنزيل جميع التبعيات المطلوبة كملفات مصدر ، اقرأ المزيد عن طريق تشغيل pip help download .

الخطأ الثالث: استخدام دوال بايثون القديمة بدلاً من طرق العرض القائمة على الفصل

في بعض الأحيان يكون من الجيد استخدام دالة Python صغيرة في ملف views.py الخاص بالتطبيق خاصة للاختبارات أو عروض الأداة المساعدة ، ولكن بشكل عام ، يجب عليك استخدام العروض المستندة إلى الفئة (CBVs) في تطبيقاتك.

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

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

لقد قمت ببناء الحزمة المسماة Django Template Names ، والتي توحد أسماء النماذج لطرق العرض الخاصة بك بناءً على اسم التطبيق واسم فئة العرض. أستخدمه كل يوم ويوفر الكثير من وقتي لاختراع الأسماء. ببساطة ضع المزيج في CBV class Detail(TemplateNames, DetailView): - وسيبدأ العمل! بالطبع ، يمكنك تجاوز وظائفي وإضافة قوالب مستجيبة للجوّال أو قوالب مختلفة لوكلاء المستخدم أو أي شيء آخر تريده.

الخطأ الرابع: كتابة وجهات نظر سمينه ونماذج نحيفة

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

يجب أن تكتب نماذج سمينة ، وجهات نظر نحيفة.

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

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

يمكنك قراءة المزيد حول المشكلة في مشروع Django Best Practices. الحل بسيط: اكتب نماذج سمينة ووجهات نظر نحيفة ، لذلك دعونا نفعل ذلك في مشروعك التالي (أو نعيد تشكيل مشروعك الحالي).

الخطأ رقم 5: ملف إعدادات ضخم لا يمكن التحكم فيه

حتى ملف إعدادات مشروع Django الجديد به الكثير من الإعدادات. في مشروع حقيقي ، ينمو ملف الإعدادات إلى أكثر من 700 سطر من التكوين وسيصبح من الصعب صيانته ، خاصة عندما تحتاج بيئات التطوير والإنتاج والتشغيل إلى تكوينات مخصصة.

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

توفر الحزمة وظيفتين - optional include — التي تدعم أحرف البدل للمسارات وتستورد ملفات التكوين الخاصة بك في نفس السياق ، مما يجعل من السهل إنشاء التكوين الخاص بك باستخدام إدخالات التكوين المعلنة في الملفات التي تم تحميلها مسبقًا. لا يؤثر على أداء Django ويمكنك استخدامه في أي مشروع.

تحقق من مثال التكوين الأدنى:

 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'), )

الخطأ رقم 6: تطبيق الكل في واحد ، هيكل تطبيق سيئ ، وتعيين موارد غير صحيح

يتكون أي مشروع Django من تطبيقات متعددة. في تدوين Django ، التطبيق عبارة عن حزمة Python تحتوي على الأقل __init__.py وملفات models.py ؛ في أحدث إصدارات Django ، لم تعد models.py مطلوبة. __init__.py يكفي.

يمكن أن تحتوي تطبيقات Django على وحدات Python ، والوحدات النمطية الخاصة بـ Django (طرق العرض ، وعناوين URL ، والنماذج ، والمسؤول ، والنماذج ، وعلامات القوالب ، وما إلى ذلك) ، والملفات الثابتة ، والقوالب ، وترحيلات قواعد البيانات ، وأوامر الإدارة ، واختبارات الوحدة ، والمزيد. يجب عليك تقسيم تطبيقات monolith الخاصة بك إلى تطبيقات صغيرة قابلة لإعادة الاستخدام باستخدام منطق بسيط. يجب أن تكون قادرًا على وصف الغرض الكامل من التطبيق في جملة أو جملتين قصيرتين. على سبيل المثال: "يسمح للمستخدمين بالتسجيل وتفعيل حساباتهم عن طريق البريد الإلكتروني."

من الجيد استدعاء مشروع مجلد 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 النمطية.

 root@c5b96c395cfb:/test# tree project/apps/portal/ project/apps/portal/ ├── __init__.py ├── admin.py ├── apps.py ├── management │ ├── __init__.py │ └── commands │ ├── __init__.py │ └── update_portal_feeds.py ├── migrations │ └── __init__.py ├── models.py ├── static │ └── portal │ ├── css │ ├── img │ └── js ├── templates │ └── portal │ └── index.html ├── templatetags │ ├── __init__.py │ └── portal.py ├── tests.py ├── urls.py └── views.py 11 directories, 14 files

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

ستنتهي ببنية مشروع مثل هذا:

 root@c5b96c395cfb:/test# tree -L 3 . ├── deploy │ ├── chef │ └── docker │ ├── devel │ └── production ├── docs ├── logs ├── manage.py ├── media ├── project │ ├── __init__.py │ ├── apps │ │ ├── auth │ │ ├── blog │ │ ├── faq │ │ ├── pages │ │ ├── portal │ │ └── users │ ├── conf │ ├── settings.py │ ├── static │ ├── templates │ ├── urls.py │ └── wsgi.py └── static └── admin ├── css ├── fonts ├── img └── js 25 directories, 5 files

في مشروع حقيقي ، بالطبع ، سيكون الأمر أكثر تعقيدًا ، لكن هذا الهيكل يجعل الأمور أبسط وأنظف.

الخطأ رقم 7: STATICFILES_DIRS و STATIC_ROOT مطوّري Newbie 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 في بيئة الإنتاج الخاصة بك!

الخطأ رقم 8: الافتراضي STATICFILES_STORAGE ، تحميل قوالب Django في الإنتاج

STATICFILES_STORAGE

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

هذا رائع ، ويمكننا القيام بذلك باستخدام بضعة أسطر في تكوين Nginx لمجلد الملفات الثابتة ، ولكن ماذا عن إبطال ذاكرة التخزين المؤقت؟ إذا قام المستخدم بتنزيل أصولنا مرة واحدة فقط ، فماذا يحدث إذا قمت بتحديث شعارك أو خطوطك أو JavaScript أو لون النص لعنصر في القائمة؟ لتجاوز ذلك ، يجب عليك إنشاء عناوين URL وأسماء ملفات فريدة لملفاتنا الثابتة في كل عملية نشر!

يمكننا القيام بذلك ببساطة عن طريق استخدام ManifestStaticFilesStorage مثل STATICFILES_STORAGE (كن حذرًا ، لا يتم تمكين التجزئة إلا في DEBUG=false ) وتشغيل أمر إدارة collectstatic الذي تمت مناقشته أعلاه. سيؤدي ذلك إلى تقليل عدد طلبات الأصول إلى موقع الإنتاج الخاص بك وسيجعل موقع الويب الخاص بك يتم عرضه بشكل أسرع.

محمل قالب Django المخبأ

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

تحقق من قسم التكوين cached.Loader للحصول على مثال جيد وتفاصيل حول كيفية القيام بذلك. لا تستخدم أداة التحميل في وضع التطوير لأنها لا تعيد تحميل القوالب الموزعة من نظام الملفات ؛ ستحتاج إلى إعادة تشغيل مشروعك باستخدام python manage.py startapp عند كل تغيير في القالب. قد يكون هذا مزعجًا أثناء التطوير ، لكنه مثالي لبيئة الإنتاج.

الخطأ رقم 9: نصوص Python النقية للمرافق أو البرامج النصية

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

تحقق أيضًا من حزمة ملحقات Django ، وهي عبارة عن مجموعة من الإضافات المخصصة لـ Django. ربما قام شخص ما بالفعل بتنفيذ أوامرك! يوجد بالفعل الكثير من أوامر المهام الشائعة.

الخطأ رقم 10: إعادة اختراع العجلة

تمتلك Django و Python آلاف الحلول الجاهزة للاستخدام. جرب البحث في Google قبل أن تكتب شيئًا ليس فريدًا ؛ من المحتمل أن يكون هناك حل غني بالميزات موجود بالفعل.

فقط حاول أن تجعل الأمور بسيطة. جوجل أولا! قم بالتثبيت والتكوين والتوسيع والدمج في مشروعك إذا وجدت حزمة جيدة الجودة ، وبالطبع ، ساهم في المصدر المفتوح عندما يكون لديك فرصة.

لتبدأ ، إليك قائمة بالحزم العامة الخاصة بي لـ Django:

• يجعل عنوان URL لوحدات Django من السهل كتابة (وقراءة) أنماط عنوان URL في تطبيقات Django باستخدام وحدات الماكرو.
• أسماء قوالب Django عبارة عن مزيج صغير يسمح لك بسهولة توحيد أسماء قوالب CBV الخاصة بك.
• تتيح لك إعدادات django-split-split تنظيم إعدادات Django في ملفات وأدلة متعددة. يمكنك تجاوز الإعدادات وتعديلها بسهولة. استخدم أحرف البدل في مسارات ملفات الإعدادات وقم بتمييز ملفات الإعدادات على أنها اختيارية.

لا تكرر نفسك (جاف)!

أنا حقا أحب منهجية DRY. لهذا السبب صنعت هيكل Django كأداة ملائمة تحتوي على بعض الميزات الرائعة حقًا خارج الصندوق:

• صور Docker للتطوير / الإنتاج ، تدار بواسطة docker-compose ، مما يسمح لك بتنسيق قائمة الحاويات بسهولة.
• سيناريو النسيج البسيط لنشر الإنتاج.
• التكوين لحزمة إعدادات Django Split مع إعدادات المصادر الأساسية والمحلية.
• Webpack مدمج في المشروع - سيتم collectstatic مجلد dist فقط بواسطة Django في أمر تجميعي.
• تكوين جميع إعدادات وميزات Django الأساسية مثل قوالب Django القابلة للتخزين المؤقت في الإنتاج ، والملفات الثابتة المجزأة ، وشريط أدوات التصحيح المتكامل ، والتسجيل ، وما إلى ذلك.

إنه هيكل عظمي جانغو جاهز للاستخدام لمشروعك القادم من البداية ، ونأمل أن يوفر لك الكثير من الوقت عن طريق تمهيد مشروعك. يحتوي Webpack على الحد الأدنى من التكوين الأساسي ، ولكنه يحتوي أيضًا على SASS مُهيأ مسبقًا للتعامل مع ملفات .scss .