أفضل ممارسات مشاريع Django لضمان سعادة المطورين ورفع إنتاجيتهم

هل ترغب في أن يستمتع فريقك بسير عمل التطوير؟ هل تعتقد أن بناء البرمجيات يجب أن يكون ممتعًا ومُرضيًا على الصعيد الوجودي؟ إذا كانت إجابتك نعم، فهذه المقالة لك.

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

أداة سطر أوامر مخصصة لمشروعك في Django

بدلاً من كتابة سلسلة طويلة من الأوامر مثل:

python3 -m venv env
source env/bin/activate
pip install -r requirements.txt
python3 manage.py makemigrations
python3 manage.py migrate
python3 manage.py collectstatic
python3 manage.py runserver

ألا يكون من الأفضل بكثير كتابة أمر واحد فقط مثل:

make start

وأن يتم كل ذلك تلقائيًا؟ أعتقد ذلك! يمكننا تحقيق ذلك باستخدام ملف Makefile ذاتي التوثيق. إليك نموذج أستخدمه كثيرًا عند تطوير تطبيقات Django الخاصة بي، مثل موقع ApplyByAPI.com:

SHELL := /bin/bash
include .env

.PHONY : help
help: ## Show this help
	@egrep -h '\s ##\s' $(MAKEFILE_LIST) | awk 'BEGIN {FS = ":.*?## "}; {printf "\033[36m%-20s\033[0m %s\n", $$1, $$2}'

.PHONY : venv
venv: ## Make a new virtual environment
	python3 -m venv $(VENV) && source $(BIN)/activate

.PHONY : install
install: venv ## Make venv and install requirements
	$(BIN)/pip install -r requirements.txt

migrate: ## Make and run migrations
	$(PYTHON) manage.py makemigrations
	$(PYTHON) manage.py migrate

db-up: ## Pull and start the Docker Postgres container in the background
	docker pull postgres
	docker-compose up -d db

db-shell: ## Access the Postgres Docker database interactively with psql
	docker exec -it container_name psql -d $(DBNAME)

.PHONY : test
test: ## Run tests
	$(PYTHON) $(APP_DIR)/manage.py test application --verbosity=0 --parallel --failfast

.PHONY : run
run: ## Run the Django server
	$(PYTHON) $(APP_DIR)/manage.py runserver

start: install migrate run ## Install requirements, apply migrations, then start development server

ستلاحظ وجود السطر include .env أعلاه. يضمن هذا أن يكون لـ make وصول إلى متغيرات البيئة المخزنة في ملف يسمى .env. يتيح ذلك لـ Make استخدام هذه المتغيرات في أوامره، على سبيل المثال، اسم بيئتي الافتراضية، أو لتمرير $(DBNAME) إلى psql.

ما هو هذا التركيب الغريب للتعليقات ##؟

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

help Show this help
venv Make a new virtual environment
install Make venv and install requirements
migrate Make and run migrations
db-up Pull and start the Docker Postgres container in the background
db-shell Access the Postgres Docker database interactively with psql
test Run tests
run Run the Django server
start Install requirements, apply migrations, then start development server

تم تغطية جميع أوامر Django المعتادة، ولدينا أمر test يقوم بتشغيل اختباراتنا بالخيارات التي نفضلها. رائع. يمكنك قراءة مقالتي الكاملة حول ملفات Makefiles ذاتية التوثيق هنا، والتي تتضمن أيضًا مثالاً لملف Makefile يستخدم pipenv.

وفر جهدك الذهني باستخدام خطافات ما قبل الالتزام (Pre-commit Hooks)

لقد كتبت سابقًا عن بعض الممارسات التقنية التي يمكن أن تسهل على الفرق تطوير برامج رائعة. أحد المجالات البديهية هو استخدام خطافات ما قبل الالتزام pre-commit hooks لتدقيق الكود قبل إرساله. يساعد هذا في الحفاظ على جودة الكود الذي يلتزم به المطورون.

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

فيما يلي ملف التكوين الخاص بي، .pre-commit-config.yaml، لمشاريع Django الخاصة بي:

fail_fast: true
repos:
  - repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v3.1.0
    hooks:
      - id: detect-aws-credentials
  - repo: https://github.com/psf/black
    rev: 19.3b0
    hooks:
      - id: black
  - repo: https://github.com/asottile/blacken-docs
    rev: v1.7.0
    hooks:
      - id: blacken-docs
        additional_dependencies: [ black==19.3b0 ]
  - repo: local
    hooks:
      - id: markdownlint
        name: markdownlint
        description: "Lint Markdown files"
        entry: markdownlint '**/*.md' --fix --ignore node_modules --config "./.markdownlint.json"
        language: node
        types: [ markdown ]

تتحقق هذه الخطافات من الالتزامات السرية العرضية، وتنسق ملفات Python باستخدام Black، وتنسق مقتطفات Python في ملفات Markdown باستخدام blacken-docs، وتدقق ملفات Markdown أيضًا. من المحتمل أن تتوفر المزيد من الخطافات المفيدة لحالة الاستخدام الخاصة بك: راجع الخطافات المدعومة للاستكشاف.

ملفات التجاهل في Git (Gitignores) المفيدة

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

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

الاختبار المستمر باستخدام إجراءات GitHub (GitHub Actions)

إذا كان فريقك يعمل على GitHub، فإن إعداد عملية اختبار باستخدام Actions يعد أمرًا سهلاً. يمكن أن تساعد الاختبارات التي تعمل في بيئة متسقة على كل pull request في القضاء على معضلات “يعمل على جهازي”. يمكنها أيضًا المساعدة في ضمان عدم جلوس أي شخص في انتظار تشغيل اختبار محليًا.

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

لقد كتبت في مناسبات عديدة عن إعداد سير عمل Actions، بما في ذلك استخدام واحد لتشغيل ملف Makefile الخاص بك، وكيفية دمج بيانات حدث GitHub. حتى أن GitHub أجرى معي مقابلة حول Actions مرة واحدة.

بالنسبة لمشاريع Django، إليك سير عمل بسيط لـ GitHub Actions يقوم بتشغيل الاختبارات بإصدار Python متسق.

name: Run Django tests
on: push
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Set up Python
        uses: actions/setup-python@v2
        with:
          python-version: '3.8'
      - name: Install dependencies
        run: make install
      - name: Run tests
        run: make test

بالنسبة لأوامر التثبيت والاختبار، لقد استخدمت ببساطة ملف Makefile الذي تم إضافته إلى المستودع. إحدى فوائد استخدام أوامر Makefile في سير عمل اختبار CI الخاص بك هي أنك تحتاج فقط إلى تحديثها في مكان واحد – ملف Makefile الخاص بك! لا مزيد من صداع “لماذا يعمل هذا محليًا ولكن ليس في CI؟!”.

إذا كنت ترغب في تعزيز مستوى الأمان لديك، يمكنك إضافة Django Security Check كـ Action أيضًا.

هيئ مشروعك في Django للنجاح

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

الخلاصة التقنية

إن تبني أفضل الممارسات في تطوير مشاريع Django ليس مجرد رفاهية، بل هو ضرورة لضمان سير عمل فعال، كود عالي الجودة، وبيئة عمل إيجابية للمطورين. من خلال أتمتة المهام المتكررة باستخدام أدوات CLI مخصصة مثل Makefile، وفرض معايير الكود عبر pre-commit hooks، وإدارة ملفات التجاهل بذكاء، وتنفيذ الاختبار المستمر من خلال GitHub Actions، يمكن للفرق تحقيق مستويات غير مسبوقة من الإنتاجية والرضا. هذه الاستراتيجيات لا تقلل فقط من الأخطاء وتوفر الوقت، بل تعزز أيضًا ثقافة التطوير التعاوني والمستدام، مما يضع الأساس لمشاريع Django ناجحة ومستقبلية.