۱۷ سؤال مهم مصاحبه Django برای ارزیابی دانش کارشناس جنگو (همراه پاسخ)

اگر در حال یادگیری Django هستید یا قصد دارید به‌عنوان یک برنامه‌نویس Django استخدام شوید، آشنایی با سؤال‌های رایج مصاحبه‌های فنی اهمیت زیادی دارد. بسیاری از شرکت‌ها علاوه بر ارزیابی مهارت برنامه‌نویسی، میزان تسلط داوطلب بر مفاهیم اصلی Django، بهینه‌سازی، امنیت، معماری پروژه، تست‌نویسی و توسعه API را نیز بررسی می‌کنند.

در این مقاله، ۱۷ سؤال مهم و پرتکرار مصاحبه Django را به همراه پاسخ‌های تشریحی، مثال‌های کاربردی و نکات کلیدی بررسی می‌کنیم. اگر بتوانید به این سؤال‌ها به‌درستی پاسخ دهید، آمادگی بسیار بیشتری برای حضور در مصاحبه‌های استخدامی خواهید داشت.

اگر هنوز Django را به‌صورت اصولی یاد نگرفته‌اید، پیشنهاد می‌کنیم ابتدا دوره آموزش جنگوی مقدماتی را بگذرانید. و سپس این مقاله را به‌عنوان مرور و آمادگی برای مصاحبه بخوانید.

در این مقاله، ۱۷ سؤال مهم مصاحبه Django را بررسی می‌کنیم؛ سؤال‌هایی که معمولاً در مصاحبه‌های استخدامی برنامه‌نویسان Django مطرح می‌شوند. همچنین توضیح می‌دهیم هر سؤال دقیقاً چه دانشی را ارزیابی می‌کند و برای مطالعه عمیق‌تر، منابع آموزشی مرتبط را نیز معرفی خواهیم کرد.

اگر هنوز با Django آشنا نیستید، پیشنهاد می‌کنیم ابتدا مقاله «جنگو چیست و چرا بهترین فریم‌ورک پایتون برای توسعه وب است؟» را مطالعه کنید.

چرا این سؤال‌ها در مصاحبه‌های Django اهمیت دارند؟

هدف مصاحبه‌کننده تنها حفظ بودن دستورات Django نیست. یک توسعه‌دهنده حرفه‌ای باید بتواند:

• ساختار داخلی Django را درک کند.

• کدهای تمیز و قابل نگهداری بنویسد.

• امنیت پروژه را تأمین کند.

• عملکرد (Performance) برنامه را بهینه کند.

• با مفاهیم معماری نرم‌افزار و توسعه پروژه‌های واقعی آشنا باشد.

به همین دلیل، بسیاری از سؤال‌های مصاحبه علاوه بر دانش تئوری، تجربه عملی شما را نیز محک می‌زنند.

 

سوالات پایه Django

۱. تفاوت Model.objects.filter() و Model.objects.get() چیست؟

چرا این سؤال در مصاحبه پرسیده می‌شود؟

این سؤال یکی از رایج‌ترین پرسش‌های مصاحبه Django است، زیرا مشخص می‌کند آیا داوطلب فقط چند دستور را حفظ کرده یا واقعاً رفتار QuerySetها و نحوه بازیابی اطلاعات از پایگاه داده را می‌شناسد.

پاسخ کوتاه

• get() برای دریافت دقیقاً یک رکورد استفاده می‌شود.

• filter() برای دریافت یک یا چند رکورد استفاده می‌شود و همیشه یک QuerySet برمی‌گرداند.

پاسخ تشریحی

متد get() زمانی مناسب است که مطمئن باشید فقط یک رکورد وجود دارد؛ مانند جستجو بر اساس id یا یک slug یکتا. اگر هیچ رکوردی پیدا نشود، استثنای DoesNotExist و اگر بیش از یک رکورد پیدا شود، استثنای MultipleObjectsReturned ایجاد خواهد شد.

در مقابل، filter() هیچ‌گاه Exception ایجاد نمی‌کند. این متد همیشه یک QuerySet برمی‌گرداند؛ حتی اگر نتیجه‌ای وجود نداشته باشد. در این حالت فقط یک QuerySet خالی دریافت خواهید کرد.

به همین دلیل معمولاً برای جستجوها، فیلتر کردن اطلاعات و نمایش لیست داده‌ها از filter() استفاده می‌شود.

مثال

# دریافت یک کاربر user = User.objects.get(username="majid")

# دریافت تمام کاربران فعال users = User.objects.filter(is_active=True)

اشتباه رایج

یکی از اشتباهات رایج این است که برنامه‌نویس از get() برای جستجویی استفاده می‌کند که ممکن است چند نتیجه داشته باشد. در چنین شرایطی برنامه با خطا مواجه می‌شود.

از طرف دیگر، برخی افراد همیشه از filter().first() استفاده می‌کنند. این کار ممکن است وجود داده‌های تکراری را مخفی کند؛ در حالی که اگر انتظار دارید فقط یک رکورد وجود داشته باشد، get() انتخاب مناسب‌تری است.

اگر من مصاحبه‌کننده بودم...

بعد از شنیدن پاسخ شما احتمالاً این سؤال‌ها را نیز می‌پرسیدم:

• اگر get() هیچ رکوردی پیدا نکند چه اتفاقی می‌افتد؟

• اگر دو رکورد پیدا شوند چه می‌شود؟

• خروجی filter() از چه نوعی است؟

• چه زمانی first() را ترجیح می‌دهید؟

از دید مدرس

در کلاس‌های Django معمولاً دانشجویان تفاوت get() و filter() را در تعداد نتایج خلاصه می‌کنند، اما تجربه نشان داده است که مشکل اصلی در مدیریت خطاهاست. اگر این دو متد را درست انتخاب کنید، کد شما خواناتر، مطمئن‌تر و قابل نگهداری‌تر خواهد بود.

۲. چرخه Request و Response در Django را توضیح دهید.

چرا این سؤال در مصاحبه پرسیده می‌شود؟

هدف این سؤال بررسی درک شما از معماری داخلی Django است. مصاحبه‌کننده می‌خواهد بداند آیا فقط از Django استفاده کرده‌اید یا می‌دانید یک درخواست از لحظه ورود تا ارسال پاسخ چه مراحلی را طی می‌کند.

پاسخ کوتاه

به طور خلاصه، چرخه درخواست و پاسخ در Django شامل این مراحل است:

1. دریافت درخواست (Request)

2. اجرای Middlewareهای ورودی

3. بررسی URL و انتخاب View مناسب

4. اجرای View

5. ارتباط با پایگاه داده (در صورت نیاز)

6. رندر Template یا تولید پاسخ JSON

7. اجرای Middlewareهای خروجی

8. ارسال Response به مرورگر

پاسخ تشریحی

هر زمان کاربر آدرس یک صفحه را در مرورگر وارد می‌کند، ابتدا درخواست به وب‌سرور ارسال می‌شود و سپس به پروژه Django می‌رسد.

در ادامه، Middlewareهای ورودی اجرا می‌شوند و عملیات مختلفی مانند بررسی امنیت، نشست کاربر یا احراز هویت را انجام می‌دهند.

سپس URL Dispatcher مسیر درخواست را با فایل urls.py مقایسه می‌کند و View مناسب را پیدا می‌کند.

View منطق برنامه را اجرا می‌کند و در صورت نیاز اطلاعات را از پایگاه داده دریافت یا ذخیره می‌کند.

در نهایت، پاسخ به صورت یک صفحه HTML، فایل JSON یا هر نوع Response دیگر تولید شده، از Middlewareهای خروجی عبور می‌کند و برای مرورگر ارسال می‌شود.

مثال

فرض کنید کاربر آدرس زیر را باز می‌کند:

/blog/django-interview-questions/

مراحل به این صورت خواهد بود:

• درخواست وارد Django می‌شود.

• فایل urls.py بررسی می‌شود.

• View مربوط به مقاله پیدا می‌شود.

• اطلاعات مقاله از پایگاه داده خوانده می‌شود.

• قالب HTML رندر می‌شود.

• صفحه برای کاربر نمایش داده می‌شود.

اشتباه رایج

بسیاری از برنامه‌نویسان تصور می‌کنند پس از وارد کردن آدرس، درخواست مستقیماً وارد View می‌شود؛ در حالی که قبل از رسیدن به View، Middlewareها و URL Dispatcher نقش مهمی در پردازش درخواست دارند.

همچنین برخی افراد تصور می‌کنند Template وظیفه پردازش منطق برنامه را دارد، در حالی که Template فقط برای نمایش داده‌ها استفاده می‌شود و منطق اصلی باید در View یا لایه‌های مناسب دیگر قرار گیرد.

اگر من مصاحبه‌کننده بودم...

بعد از پاسخ شما احتمالاً این سؤال‌ها را نیز مطرح می‌کردم:

• Middleware قبل از View اجرا می‌شود یا بعد از آن؟

• اگر هیچ URL منطبق پیدا نشود چه پاسخی برمی‌گردد؟

• تفاوت HttpRequest و HttpResponse چیست؟

• آیا همیشه View یک Template رندر می‌کند؟

از دید مدرس

یکی از مشکلات رایج دانشجویان این است که Django را مانند یک جعبه سیاه می‌بینند؛ یعنی فقط View می‌نویسند و خروجی را مشاهده می‌کنند، بدون اینکه بدانند درخواست چه مسیری را طی کرده است. وقتی چرخه Request و Response را به‌خوبی درک کنید، اشکال‌زدایی پروژه، نوشتن Middleware و حتی توسعه API برایتان بسیار ساده‌تر خواهد شد.

۳. تفاوت Function-Based View و Class-Based View چیست؟

چرا این سؤال در مصاحبه پرسیده می‌شود؟

این سؤال نشان می‌دهد که آیا با معماری Viewها در Django آشنا هستید یا خیر. مصاحبه‌کننده می‌خواهد بداند آیا می‌توانید با توجه به نیاز پروژه، مناسب‌ترین نوع View را انتخاب کنید یا صرفاً از یک روش ثابت استفاده می‌کنید.

پاسخ کوتاه

• Function-Based View (FBV) برای پروژه‌های ساده و منطق‌های کوتاه مناسب‌تر است.

• Class-Based View (CBV) برای پروژه‌های بزرگ، کدهای قابل استفاده مجدد و امکانات پیشرفته Django انتخاب بهتری است.

پاسخ تشریحی

در Function-Based View هر View به صورت یک تابع پایتون نوشته می‌شود. این روش ساده، خوانا و برای افراد تازه‌کار قابل فهم‌تر است.

در مقابل، Class-Based View بر پایه کلاس‌ها و برنامه‌نویسی شیءگرا طراحی شده است. در این روش می‌توان از وراثت (Inheritance)، Generic Viewها و Mixinها استفاده کرد و حجم زیادی از کدنویسی تکراری را حذف نمود.

به همین دلیل در پروژه‌های متوسط و بزرگ، معمولاً استفاده از Class-Based View باعث افزایش خوانایی، توسعه‌پذیری و نگهداری بهتر پروژه می‌شود.

مثال

Function-Based View

from django.shortcuts import render def course_list(request): return render(request, "courses/list.html")

Class-Based View

from django.views.generic import ListView from .models import Course class CourseListView(ListView): model = Course template_name = "courses/list.html"

اشتباه رایج

بعضی از برنامه‌نویسان تصور می‌کنند Class-Based View همیشه بهتر از Function-Based View است؛ در حالی که این موضوع به نیاز پروژه بستگی دارد.

اگر فقط قرار است چند خط کد بنویسید، استفاده از یک Class-Based View ممکن است پروژه را بی‌دلیل پیچیده کند. از طرف دیگر، در پروژه‌های بزرگ استفاده بیش از حد از Function-Based View می‌تواند باعث تکرار کدها و کاهش قابلیت نگهداری شود.

اگر من مصاحبه‌کننده بودم...

بعد از پاسخ شما احتمالاً این سؤال‌ها را مطرح می‌کردم:

• مزیت Generic Viewها چیست؟

• متد dispatch() چه کاری انجام می‌دهد؟

• چه زمانی از ListView استفاده می‌کنید؟

• Mixin چیست و چه کاربردی دارد؟

• آیا می‌توان احراز هویت را در CBV ساده‌تر پیاده‌سازی کرد؟

از دید مدرس

یکی از اشتباهات رایج دانشجویان این است که بعد از یاد گرفتن Class-Based View، دیگر از Function-Based View استفاده نمی‌کنند. در حالی که یک برنامه‌نویس حرفه‌ای ابزار مناسب را برای مسئله مناسب انتخاب می‌کند. اگر یک View فقط چند خط منطق ساده دارد، FBV کاملاً منطقی است؛ اما وقتی منطق پروژه بزرگ‌تر می‌شود، CBV با امکاناتی مانند Generic Viewها و Mixinها ارزش واقعی خود را نشان می‌دهد.

۴. فایل settings.py چه نقشی در پروژه Django دارد؟

چرا این سؤال در مصاحبه پرسیده می‌شود؟

این سؤال نشان می‌دهد که آیا با تنظیمات اصلی پروژه Django آشنا هستید یا فقط به نوشتن View و Model محدود شده‌اید. یک توسعه‌دهنده حرفه‌ای باید بداند هر بخش از فایل settings.py چه تأثیری بر عملکرد، امنیت و ساختار پروژه دارد.

پاسخ کوتاه

فایل settings.py مرکز مدیریت تنظیمات پروژه Django است. تقریباً تمام تنظیمات مهم پروژه مانند پایگاه داده، برنامه‌های نصب‌شده، فایل‌های استاتیک، امنیت، قالب‌ها و Middlewareها در این فایل قرار دارند.

پاسخ تشریحی

هر پروژه Django یک فایل settings.py دارد که تنظیمات کلی پروژه در آن ذخیره می‌شود.

از مهم‌ترین بخش‌های این فایل می‌توان به موارد زیر اشاره کرد:

• INSTALLED_APPS برای معرفی اپلیکیشن‌های پروژه

• DATABASES برای اتصال به پایگاه داده

• MIDDLEWARE برای مدیریت درخواست‌ها و پاسخ‌ها

• TEMPLATES برای تنظیم قالب‌های HTML

• STATIC_URL و STATICFILES_DIRS برای فایل‌های CSS و JavaScript

• MEDIA_URL و MEDIA_ROOT برای فایل‌های بارگذاری‌شده

• LANGUAGE_CODE و TIME_ZONE برای تنظیم زبان و منطقه زمانی

• DEBUG برای تعیین حالت توسعه یا انتشار

• ALLOWED_HOSTS برای مشخص کردن دامنه‌های مجاز

تسلط بر این تنظیمات برای توسعه، دیپلوی و نگهداری پروژه ضروری است.

مثال

نمونه‌ای از معرفی اپلیکیشن‌ها:

INSTALLED_APPS = [ "accounts", "courses", "blog", "ckeditor", ]

نمونه‌ای از تنظیم پایگاه داده:

DATABASES = { "default": { "ENGINE": "django.db.backends.sqlite3", "NAME": BASE_DIR / "db.sqlite3", } }

اشتباه رایج

یکی از رایج‌ترین اشتباهات، انتشار پروژه با DEBUG=True است. این کار می‌تواند اطلاعات حساس پروژه را در صورت بروز خطا در اختیار کاربران قرار دهد.

اشتباه دیگر، قرار دادن SECRET_KEY به صورت ثابت در مخزن Git است. در پروژه‌های واقعی بهتر است این مقدار از متغیرهای محیطی (Environment Variables) خوانده شود.

همچنین بسیاری از افراد پس از دیپلوی، مقدار ALLOWED_HOSTS را تنظیم نمی‌کنند و با خطای DisallowedHost مواجه می‌شوند.

اگر من مصاحبه‌کننده بودم...

بعد از پاسخ شما احتمالاً این سؤال‌ها را نیز مطرح می‌کردم:

• تفاوت DEBUG=True و DEBUG=False چیست؟

• چرا نباید SECRET_KEY را در GitHub قرار داد؟

• ALLOWED_HOSTS چه کاربردی دارد؟

• تفاوت STATIC_ROOT و STATICFILES_DIRS چیست؟

• چرا در محیط Production معمولاً از فایل تنظیمات جداگانه استفاده می‌شود؟

از دید مدرس

یکی از نکاتی که همیشه به دانشجویان می‌گویم این است که یادگیری Django فقط به Model و View محدود نمی‌شود. بسیاری از مشکلاتی که هنگام دیپلوی پروژه به وجود می‌آید، به دلیل آشنا نبودن با فایل settings.py است. هرچه زودتر با تنظیمات این فایل راحت شوید، راه‌اندازی و مدیریت پروژه‌ها برایتان بسیار ساده‌تر خواهد شد.

۵. Django ORM چیست و چه مزایایی نسبت به SQL خام دارد؟

چرا این سؤال در مصاحبه پرسیده می‌شود؟

این سؤال میزان آشنایی شما با یکی از مهم‌ترین قابلیت‌های Django را ارزیابی می‌کند. مصاحبه‌کننده می‌خواهد بداند آیا فقط دستورات ORM را حفظ کرده‌اید یا فلسفه استفاده از آن، مزایا و محدودیت‌هایش را نیز می‌شناسید.

پاسخ کوتاه

ORM یا Object Relational Mapping لایه‌ای است که امکان کار با پایگاه داده را از طریق کلاس‌ها و اشیای پایتون فراهم می‌کند؛ بدون اینکه در بیشتر مواقع نیازی به نوشتن دستورات SQL داشته باشید.

پاسخ تشریحی

در Django هر Model معادل یک جدول در پایگاه داده است و هر شیء از آن Model، نماینده یک رکورد از همان جدول محسوب می‌شود.

به جای نوشتن Queryهای SQL، می‌توانید از متدهای ORM مانند filter()، get()، create() و update() استفاده کنید. Django این دستورات را به Queryهای مناسب برای پایگاه داده تبدیل می‌کند.

مهم‌ترین مزایای ORM عبارت‌اند از:

• خوانایی بیشتر کد

• کاهش احتمال بروز SQL Injection

• استقلال از نوع پایگاه داده

• توسعه و نگهداری آسان‌تر پروژه

• یکپارچگی کامل با سایر بخش‌های Django مانند Migration و Modelها

البته در برخی سناریوهای پیچیده یا گزارش‌های خاص، استفاده از SQL خام نیز می‌تواند انتخاب مناسبی باشد.

مثال

به جای نوشتن این Query در SQL:

SELECT * FROM blog_blogpost WHERE is_published = TRUE;

در Django می‌توان نوشت:

posts = BlogPost.objects.filter(is_published=True)

یا برای ایجاد یک رکورد جدید:

BlogPost.objects.create( title="آموزش Django", author=request.user, )

اشتباه رایج

بعضی از برنامه‌نویسان تصور می‌کنند ORM همیشه از SQL سریع‌تر است، در حالی که ORM فقط یک ابزار برای ساده‌تر و ایمن‌تر کردن توسعه است و در نهایت خودش نیز Queryهای SQL تولید می‌کند.

اشتباه رایج دیگر این است که بدون بررسی Queryهای تولیدشده، تعداد زیادی Query غیرضروری اجرا می‌کنند و باعث کاهش شدید عملکرد پروژه می‌شوند. آشنایی با ابزارهایی مانند select_related() و prefetch_related() برای جلوگیری از این مشکلات ضروری است.

اگر من مصاحبه‌کننده بودم...

بعد از پاسخ شما احتمالاً این سؤال‌ها را نیز مطرح می‌کردم:

• ORM چگونه از SQL Injection جلوگیری می‌کند؟

• چه زمانی از raw() استفاده می‌کنید؟

• تفاوت save() و create() چیست؟

• آیا ORM روی همه پایگاه‌های داده یکسان عمل می‌کند؟

• چگونه Queryهای تولیدشده توسط ORM را مشاهده می‌کنید؟

از دید مدرس

بسیاری از دانشجویان بعد از یادگیری چند متد ORM تصور می‌کنند این بخش را کاملاً یاد گرفته‌اند. اما مهارت واقعی زمانی شکل می‌گیرد که بتوانید Queryهای بهینه بنویسید، تعداد درخواست‌ها به پایگاه داده را کاهش دهید و در صورت نیاز، تشخیص دهید چه زمانی استفاده از SQL خام منطقی‌تر است. هدف ORM فقط حذف SQL نیست؛ هدف، توسعه سریع‌تر، خواناتر و ایمن‌تر نرم‌افزار است.

سوالات سطح متوسط

۶. تفاوت select_related() و prefetch_related() چیست؟

چرا این سؤال در مصاحبه پرسیده می‌شود؟

این سؤال برای ارزیابی میزان آشنایی شما با بهینه‌سازی Queryها در Django مطرح می‌شود. بسیاری از پروژه‌های واقعی به دلیل استفاده نادرست از ارتباط بین Modelها با مشکل N+1 Query و کاهش شدید سرعت مواجه می‌شوند. مصاحبه‌کننده می‌خواهد مطمئن شود که می‌توانید این مشکل را تشخیص داده و برطرف کنید.

پاسخ کوتاه

• select_related() برای ارتباط‌های ForeignKey و OneToOneField استفاده می‌شود.

• prefetch_related() برای ارتباط‌های ManyToManyField و Reverse ForeignKey استفاده می‌شود.

پاسخ تشریحی

به طور پیش‌فرض، وقتی اطلاعات یک مدل مرتبط را فراخوانی می‌کنید، Django برای هر شیء یک Query جداگانه اجرا می‌کند. اگر تعداد رکوردها زیاد باشد، تعداد Queryها به شدت افزایش پیدا می‌کند و عملکرد پروژه کاهش می‌یابد.

متد select_related() با استفاده از JOIN اطلاعات مدل‌های مرتبط را در یک Query دریافت می‌کند و برای ارتباط‌های یک‌به‌یک و چندبه‌یک مناسب است.

در مقابل، prefetch_related() ابتدا Query اصلی را اجرا می‌کند و سپس اطلاعات مدل‌های مرتبط را با Queryهای جداگانه دریافت و در حافظه به یکدیگر متصل می‌کند. این روش برای ارتباط‌های چندبه‌چند و ارتباط‌های معکوس بهترین انتخاب است.

مثال

فرض کنید هر مقاله یک نویسنده دارد.

بدون بهینه‌سازی:

posts = BlogPost.objects.all()

با select_related():

posts = BlogPost.objects.select_related("author")

اگر هر مقاله چند برچسب داشته باشد:

posts = BlogPost.objects.prefetch_related("tags")

اشتباه رایج

یکی از رایج‌ترین اشتباهات، استفاده از select_related() برای فیلدهای ManyToManyField است؛ در حالی که این متد از چنین ارتباطی پشتیبانی نمی‌کند.

اشتباه دیگر، استفاده نکردن از هیچ‌یک از این دو متد در صفحه‌هایی است که تعداد زیادی داده مرتبط نمایش می‌دهند. نتیجه این کار اجرای ده‌ها یا حتی صدها Query غیرضروری و کاهش محسوس سرعت سایت خواهد بود.

اگر من مصاحبه‌کننده بودم...

بعد از پاسخ شما احتمالاً این سؤال‌ها را نیز مطرح می‌کردم:

• مشکل N+1 Query چیست؟

• select_related() از چه نوع JOIN استفاده می‌کند؟

• آیا می‌توان select_related() و prefetch_related() را هم‌زمان استفاده کرد؟

• از کجا متوجه می‌شوید تعداد Queryهای پروژه زیاد شده است؟

از دید مدرس

بیشتر دانشجویان ابتدا فقط روی درست کار کردن برنامه تمرکز می‌کنند، اما در پروژه‌های واقعی سرعت نیز اهمیت زیادی دارد. یکی از اولین مهارت‌هایی که یک برنامه‌نویس Django را حرفه‌ای نشان می‌دهد، این است که بتواند با چند تغییر ساده، تعداد Queryهای پایگاه داده را از صدها Query به چند Query محدود کند.

۷. Migration در Django چگونه کار می‌کند؟

چرا این سؤال در مصاحبه پرسیده می‌شود؟

این سؤال نشان می‌دهد که آیا فقط با Modelها کار کرده‌اید یا فرآیند تغییر ساختار پایگاه داده را نیز درک می‌کنید. تقریباً تمام پروژه‌های Django از Migration استفاده می‌کنند و یک توسعه‌دهنده حرفه‌ای باید بتواند آن را مدیریت کند.

پاسخ کوتاه

Migration مکانیزمی در Django است که تغییرات Modelها را به تغییرات قابل اجرا روی پایگاه داده تبدیل می‌کند. به کمک آن می‌توان بدون نوشتن SQL، ساختار دیتابیس را به‌روزرسانی کرد.

پاسخ تشریحی

هر زمان که Modelهای پروژه را تغییر دهید؛ مانند اضافه کردن یک فیلد، حذف یک فیلد یا تغییر نوع داده، ابتدا باید فایل Migration ایجاد شود.

فرآیند معمول به این شکل است:

1. تغییر Modelها

2. اجرای دستور python manage.py makemigrations

3. ایجاد فایل Migration

4. اجرای دستور python manage.py migrate

5. اعمال تغییرات روی پایگاه داده

فایل‌های Migration تاریخچه تغییرات ساختار پایگاه داده را نگهداری می‌کنند و باعث می‌شوند تمام اعضای تیم بتوانند ساختار یکسانی از دیتابیس داشته باشند.

مثال

ایجاد فایل Migration:

python manage.py makemigrations

اجرای Migration:

python manage.py migrate

مشاهده وضعیت Migrationها:

python manage.py showmigrations

اشتباه رایج

یکی از رایج‌ترین اشتباهات این است که برنامه‌نویس Model را تغییر می‌دهد اما دستور makemigrations یا migrate را اجرا نمی‌کند. در نتیجه، ساختار Model و پایگاه داده با یکدیگر هماهنگ نخواهند بود.

اشتباه دیگر، حذف دستی فایل‌های Migration بدون آگاهی از وابستگی آن‌هاست. این کار می‌تواند باعث بروز خطاهای پیچیده و از بین رفتن تاریخچه تغییرات پروژه شود.

اگر من مصاحبه‌کننده بودم...

بعد از پاسخ شما احتمالاً این سؤال‌ها را نیز مطرح می‌کردم:

• تفاوت makemigrations و migrate چیست؟

• اگر دو برنامه‌نویس Migration متفاوتی ایجاد کنند، چگونه Conflict را برطرف می‌کنید؟

• دستور showmigrations چه کاربردی دارد؟

• آیا می‌توان یک Migration را Rollback کرد؟

از دید مدرس

بسیاری از دانشجویان در ابتدای یادگیری Django تصور می‌کنند Migration فقط یک دستور است که باید بعد از تغییر Model اجرا شود. اما در پروژه‌های تیمی، Migration در واقع تاریخچه تکامل پایگاه داده است. هرچه این مفهوم را بهتر درک کنید، هنگام توسعه و انتشار پروژه با مشکلات بسیار کمتری روبه‌رو خواهید شد.

۸. تفاوت null=True و blank=True چیست؟

چرا این سؤال در مصاحبه پرسیده می‌شود؟

این سؤال یکی از متداول‌ترین پرسش‌های مصاحبه Django است، زیرا بسیاری از برنامه‌نویسان تازه‌کار این دو گزینه را با یکدیگر اشتباه می‌گیرند. مصاحبه‌کننده می‌خواهد مطمئن شود که تفاوت اعتبارسنجی فرم‌ها و نحوه ذخیره‌سازی داده‌ها در پایگاه داده را به‌خوبی می‌شناسید.

پاسخ کوتاه

• null=True به پایگاه داده مربوط است.

• blank=True به اعتبارسنجی فرم‌ها مربوط است.

پاسخ تشریحی

وقتی برای یک فیلد null=True قرار می‌دهید، Django اجازه می‌دهد مقدار NULL در پایگاه داده ذخیره شود. بنابراین این گزینه مستقیماً بر ساختار و نحوه ذخیره اطلاعات در دیتابیس تأثیر می‌گذارد.

در مقابل، blank=True مشخص می‌کند که آیا کاربر می‌تواند هنگام ارسال فرم، آن فیلد را خالی بگذارد یا خیر. این گزینه فقط در مرحله اعتبارسنجی فرم‌ها و ModelFormها بررسی می‌شود و ارتباطی با نوع ذخیره‌سازی در پایگاه داده ندارد.

در بسیاری از پروژه‌ها این دو گزینه در کنار هم استفاده می‌شوند، اما همیشه لازم نیست هر دو مقدار True داشته باشند.

مثال

فیلدی که هم در فرم اختیاری است و هم می‌تواند در پایگاه داده مقدار NULL داشته باشد:

bio = models.TextField( blank=True, null=True )

فیلدی که در فرم اختیاری است، اما در پایگاه داده مقدار NULL ذخیره نمی‌شود:

first_name = models.CharField( max_length=100, blank=True )

اشتباه رایج

یکی از رایج‌ترین اشتباهات این است که برای تمام CharFieldها از null=True استفاده می‌کنند. در Django معمولاً برای فیلدهای متنی، مقدار خالی ("") به جای NULL ذخیره می‌شود و در بیشتر موارد نیازی به null=True نیست.

اشتباه دیگر این است که تصور می‌کنند blank=True باعث می‌شود مقدار NULL در پایگاه داده ذخیره شود؛ در حالی که این گزینه فقط اعتبارسنجی فرم را کنترل می‌کند.

اگر من مصاحبه‌کننده بودم...

بعد از پاسخ شما احتمالاً این سؤال‌ها را نیز مطرح می‌کردم:

• چرا معمولاً برای CharField از null=True استفاده نمی‌شود؟

• آیا blank=True روی پایگاه داده تأثیری دارد؟

• اگر فقط null=True باشد، فرم چه رفتاری خواهد داشت؟

• اگر فقط blank=True باشد، مقدار ذخیره‌شده در پایگاه داده چیست؟

از دید مدرس

این سؤال شاید ساده به نظر برسد، اما تجربه تدریس نشان داده است که یکی از بیشترین خطاهای دانشجویان دقیقاً در همین بخش رخ می‌دهد. اگر از همان ابتدا تفاوت بین «اعتبارسنجی فرم» و «ذخیره‌سازی در پایگاه داده» را به‌خوبی درک کنید، بسیاری از ابهام‌های مربوط به Modelها برایتان برطرف خواهد شد.

۹. Signals در Django چیست؟

چرا این سؤال در مصاحبه پرسیده می‌شود؟

این سؤال نشان می‌دهد که آیا با ارتباط غیرمستقیم بین بخش‌های مختلف پروژه آشنا هستید یا خیر. مصاحبه‌کننده می‌خواهد بداند چه زمانی استفاده از Signal منطقی است و چه زمانی بهتر است از آن استفاده نشود.

پاسخ کوتاه

Signal مکانیزمی در Django است که به شما اجازه می‌دهد هنگام وقوع یک رویداد (مانند ایجاد، ویرایش یا حذف یک شیء)، بدون تغییر کد اصلی، عملیات دیگری را به‌صورت خودکار اجرا کنید.

پاسخ تشریحی

فرض کنید هر بار که یک کاربر جدید ثبت‌نام می‌کند، می‌خواهید به‌طور خودکار پروفایل او ایجاد شود.

اگر این کد را داخل View بنویسید، هر جایی که کاربر ایجاد شود باید آن را تکرار کنید.

اما با استفاده از Signal، هر زمان شیء User ایجاد شود، Django به‌صورت خودکار تابع موردنظر را اجرا می‌کند.

رایج‌ترین Signalها عبارت‌اند از:

• post_save

• pre_save

• post_delete

• pre_delete

• m2m_changed

مثال

ایجاد خودکار پروفایل پس از ثبت‌نام کاربر:

from django.db.models.signals import post_save from django.dispatch import receiver from .models import User, Profile @receiver(post_save, sender=User) def create_profile(sender, instance, created, **kwargs): if created: Profile.objects.create(user=instance)

در این مثال، هر زمان یک کاربر جدید ایجاد شود، پروفایل مربوط به او نیز به‌صورت خودکار ساخته خواهد شد.

اشتباه رایج

یکی از رایج‌ترین اشتباهات این است که تمام منطق پروژه را داخل Signalها قرار می‌دهند. این کار باعث می‌شود مسیر اجرای برنامه نامشخص شود و اشکال‌زدایی پروژه بسیار دشوار گردد.

همچنین بعضی از برنامه‌نویسان فراموش می‌کنند فایل signals.py را در متد ready() اپلیکیشن بارگذاری کنند؛ در نتیجه Signal اصلاً اجرا نمی‌شود.

اگر من مصاحبه‌کننده بودم...

بعد از پاسخ شما احتمالاً این سؤال‌ها را نیز مطرح می‌کردم:

• تفاوت pre_save و post_save چیست؟

• چرا استفاده بیش از حد از Signal توصیه نمی‌شود؟

• چگونه فایل signals.py را فعال می‌کنید؟

• آیا Signal هنگام اجرای bulk_create() نیز اجرا می‌شود؟

از دید مدرس

بیشتر دانشجویان بعد از آشنایی با Signalها، سعی می‌کنند همه چیز را با آن‌ها پیاده‌سازی کنند. اما تجربه پروژه‌های واقعی نشان می‌دهد که Signal باید فقط برای کارهای جانبی و مستقل استفاده شود؛ مانند ساخت پروفایل، ارسال ایمیل یا ثبت لاگ. اگر منطق اصلی برنامه داخل Signalها قرار بگیرد، نگهداری پروژه در آینده بسیار دشوار خواهد شد.

۱۰. Middleware در Django چگونه کار می‌کند؟

چرا این سؤال در مصاحبه پرسیده می‌شود؟

این سؤال میزان آشنایی شما با چرخه پردازش درخواست و پاسخ در Django را ارزیابی می‌کند. مصاحبه‌کننده می‌خواهد مطمئن شود که می‌دانید Middleware در چه مرحله‌ای اجرا می‌شود، چه کاربردی دارد و در چه شرایطی باید از آن استفاده کرد.

پاسخ کوتاه

Middleware مجموعه‌ای از کلاس‌هاست که قبل از رسیدن درخواست به View و همچنین قبل از ارسال پاسخ به مرورگر اجرا می‌شوند و می‌توانند درخواست یا پاسخ را تغییر دهند.

پاسخ تشریحی

وقتی کاربر درخواستی به پروژه Django ارسال می‌کند، این درخواست ابتدا از میان Middlewareها عبور می‌کند. هر Middleware می‌تواند عملیاتی مانند احراز هویت، بررسی امنیت، مدیریت Session، ثبت لاگ یا تغییر درخواست را انجام دهد.

پس از اجرای View و تولید پاسخ، Response نیز دوباره از همان Middlewareها عبور می‌کند و در صورت نیاز تغییر داده می‌شود. در نهایت پاسخ برای مرورگر ارسال خواهد شد.

به همین دلیل Middleware مکان مناسبی برای پیاده‌سازی قابلیت‌هایی است که باید روی تمام درخواست‌های پروژه اعمال شوند.

مثال

نمونه‌ای از ثبت یک Middleware در فایل settings.py:

MIDDLEWARE = [ "django.middleware.security.SecurityMiddleware", "django.contrib.sessions.middleware.SessionMiddleware", "django.middleware.common.CommonMiddleware", ]

نمونه‌ای از یک Middleware ساده:

class SimpleMiddleware: def __init__(self, get_response): self.get_response = get_response def __call__(self, request): response = self.get_response(request) return response

اشتباه رایج

یکی از رایج‌ترین اشتباهات این است که منطق مربوط به یک View خاص را داخل Middleware قرار می‌دهند. Middleware باید فقط برای عملیات عمومی که روی تمام یا بخش بزرگی از درخواست‌ها اعمال می‌شود استفاده شود.

اشتباه دیگر، تغییر ترتیب Middlewareها در فایل settings.py بدون آگاهی از وابستگی آن‌هاست. ترتیب اجرای Middlewareها اهمیت زیادی دارد و تغییر نادرست آن می‌تواند باعث بروز مشکلات امنیتی یا عملکردی شود.

اگر من مصاحبه‌کننده بودم...

بعد از پاسخ شما احتمالاً این سؤال‌ها را نیز مطرح می‌کردم:

• Middleware قبل از View اجرا می‌شود یا بعد از آن؟

• آیا می‌تواند درخواست را متوقف کند؟

• تفاوت Middleware و Decorator چیست؟

• چگونه یک Middleware اختصاصی ایجاد می‌کنید؟

• چرا ترتیب Middlewareها در settings.py مهم است؟

از دید مدرس

بسیاری از دانشجویان در ابتدای یادگیری Django تصور می‌کنند Middleware فقط یک فایل تنظیماتی است، اما در پروژه‌های واقعی یکی از مهم‌ترین ابزارهای مدیریت درخواست‌ها محسوب می‌شود. اگر بدانید چه کدی باید در Middleware قرار بگیرد و چه کدی نباید قرار بگیرد، معماری پروژه شما بسیار تمیزتر و قابل نگهداری‌تر خواهد بود.

۱۱. تفاوت Django Forms و Django REST Framework Serializers چیست؟

چرا این سؤال در مصاحبه پرسیده می‌شود؟

این سؤال میزان آشنایی شما با توسعه وب و API را ارزیابی می‌کند. مصاحبه‌کننده می‌خواهد بداند آیا تفاوت بین اعتبارسنجی داده‌ها در صفحات وب و سرویس‌های REST را به‌خوبی درک کرده‌اید یا خیر.

پاسخ کوتاه

• Django Forms برای دریافت، اعتبارسنجی و پردازش اطلاعات در صفحات HTML استفاده می‌شود.

• Django REST Framework Serializers برای اعتبارسنجی، تبدیل و ارسال داده‌ها در APIهای REST کاربرد دارند.

پاسخ تشریحی

وقتی در حال توسعه یک وب‌سایت معمولی با قالب‌های HTML هستید، کاربران اطلاعات را از طریق فرم‌ها ارسال می‌کنند. در این حالت، Django Forms مسئول اعتبارسنجی داده‌ها، نمایش خطاها و پردازش اطلاعات است.

اما اگر در حال توسعه یک API باشید، معمولاً داده‌ها به صورت JSON بین کلاینت و سرور رد و بدل می‌شوند. در این شرایط، Serializerهای Django REST Framework علاوه بر اعتبارسنجی، وظیفه تبدیل داده‌های Model به JSON و بالعکس را نیز بر عهده دارند.

به بیان ساده، Forms برای صفحات وب طراحی شده‌اند، در حالی که Serializerها برای ارتباط برنامه‌ها از طریق API استفاده می‌شوند.

مثال

نمونه‌ای از یک Form:

class ContactForm(forms.Form): name = forms.CharField() email = forms.EmailField()

نمونه‌ای از یک Serializer:

class CourseSerializer(serializers.ModelSerializer): class Meta: model = Course fields = "__all__"

اشتباه رایج

یکی از اشتباهات رایج این است که برنامه‌نویسان تصور می‌کنند Serializer فقط نسخه دیگری از Form است. در حالی که Serializer علاوه بر اعتبارسنجی، وظیفه تبدیل داده‌ها بین Model و فرمت‌هایی مانند JSON را نیز بر عهده دارد.

اشتباه دیگر، استفاده از Django Forms برای توسعه API است؛ در حالی که برای APIهای REST باید از Serializerهای Django REST Framework استفاده شود.

اگر من مصاحبه‌کننده بودم...

بعد از پاسخ شما احتمالاً این سؤال‌ها را نیز مطرح می‌کردم:

• تفاوت Serializer و ModelSerializer چیست؟

• آیا Serializer می‌تواند داده‌ها را اعتبارسنجی کند؟

• خروجی Serializer معمولاً در چه فرمتی است؟

• آیا می‌توان بدون Django REST Framework نیز API نوشت؟

از دید مدرس

یکی از اشتباهات رایج دانشجویان این است که پس از یادگیری Django، تصور می‌کنند همان دانش برای توسعه API نیز کافی است. اما زمانی که وارد دنیای REST می‌شوید، Serializerها نقش بسیار مهمی پیدا می‌کنند. اگر تفاوت Forms و Serializerها را به‌خوبی درک کنید، یادگیری Django REST Framework برایتان بسیار ساده‌تر خواهد شد.

سوالات پیشرفته

۱۲. چگونه عملکرد (Performance) پروژه Django را بهینه می‌کنید؟

چرا این سؤال در مصاحبه پرسیده می‌شود؟

این سؤال نشان می‌دهد که آیا تجربه کار روی پروژه‌های واقعی را دارید یا خیر. نوشتن برنامه‌ای که فقط درست کار کند کافی نیست؛ یک توسعه‌دهنده حرفه‌ای باید بتواند سرعت، مصرف منابع و مقیاس‌پذیری پروژه را نیز بهبود دهد.

پاسخ کوتاه

برای بهینه‌سازی عملکرد پروژه Django معمولاً از روش‌های زیر استفاده می‌شود:

• بهینه‌سازی Queryهای پایگاه داده

• استفاده از select_related() و prefetch_related()

• استفاده از Cache

• ایجاد Index برای فیلدهای پرکاربرد

• صفحه‌بندی (Pagination)

• بارگذاری تنبل (Lazy Loading)

• استفاده از ابزارهای Profiling و تحلیل Queryها

پاسخ تشریحی

بهینه‌سازی عملکرد از بخش‌های مختلفی تشکیل شده است.

اولین قدم، کاهش تعداد Queryهای پایگاه داده است؛ زیرا معمولاً بیشترین زمان اجرای برنامه صرف ارتباط با دیتابیس می‌شود.

در مرحله بعد، داده‌هایی که زیاد تغییر نمی‌کنند می‌توانند با استفاده از Cache در حافظه ذخیره شوند تا نیازی به اجرای Queryهای تکراری نباشد.

همچنین ایجاد Index روی ستون‌هایی که زیاد جستجو می‌شوند، سرعت بازیابی اطلاعات را افزایش می‌دهد.

برای صفحاتی که تعداد زیادی داده نمایش می‌دهند، استفاده از Pagination ضروری است تا فقط اطلاعات موردنیاز هر صفحه بارگذاری شود.

در نهایت، ابزارهایی مانند Django Debug Toolbar به شما کمک می‌کنند تعداد Queryها و بخش‌های کند پروژه را شناسایی کنید.

مثال

بهینه‌سازی Query:

posts = BlogPost.objects.select_related( "author" ).prefetch_related( "tags" )

استفاده از Cache:

from django.core.cache import cache posts = cache.get("latest_posts")

اشتباه رایج

یکی از رایج‌ترین اشتباهات این است که بدون اندازه‌گیری، شروع به بهینه‌سازی پروژه می‌کنند. همیشه ابتدا باید مشخص شود گلوگاه (Bottleneck) پروژه کجاست.

اشتباه دیگر، استفاده بیش از حد از Cache است. اگر داده‌هایی که مرتب تغییر می‌کنند در Cache ذخیره شوند، ممکن است کاربران اطلاعات قدیمی مشاهده کنند.

همچنین برخی توسعه‌دهندگان تعداد زیاد Queryها را نادیده می‌گیرند و فقط روی قدرت سخت‌افزار سرور حساب می‌کنند؛ در حالی که بهینه‌سازی Queryها معمولاً تأثیر بسیار بیشتری دارد.

اگر من مصاحبه‌کننده بودم...

بعد از پاسخ شما احتمالاً این سؤال‌ها را نیز مطرح می‌کردم:

• مشکل N+1 Query چیست؟

• چه زمانی از Redis برای Cache استفاده می‌کنید؟

• تفاوت Cache سمت سرور و Cache مرورگر چیست؟

• چگونه Queryهای کند را پیدا می‌کنید؟

• Index چه تأثیری بر سرعت جستجو دارد؟

از دید مدرس

یکی از تفاوت‌های اصلی بین یک برنامه‌نویس مبتدی و حرفه‌ای این است که برنامه‌نویس حرفه‌ای فقط به «درست اجرا شدن» برنامه فکر نمی‌کند؛ بلکه همیشه از خودش می‌پرسد: «آیا راه سریع‌تر و بهینه‌تری هم وجود دارد؟» این طرز فکر در پروژه‌های بزرگ اهمیت بسیار زیادی دارد و کیفیت نرم‌افزار را به شکل محسوسی افزایش می‌دهد.

۱۳. آیا با Celery کار کرده‌اید؟

چرا این سؤال در مصاحبه پرسیده می‌شود؟

این سؤال برای بررسی تجربه شما در توسعه پروژه‌های واقعی مطرح می‌شود. بسیاری از برنامه‌ها وظایفی دارند که اجرای آن‌ها زمان‌بر است و نباید باعث منتظر ماندن کاربر شوند. مصاحبه‌کننده می‌خواهد بداند آیا با پردازش‌های پس‌زمینه (Background Tasks) آشنا هستید یا خیر.

پاسخ کوتاه

Celery یک ابزار برای اجرای وظایف زمان‌بر به‌صورت غیرهمزمان (Asynchronous) است. به کمک آن می‌توان کارهایی مانند ارسال ایمیل، پردازش تصویر، تولید گزارش یا ارسال پیامک را در پس‌زمینه اجرا کرد.

پاسخ تشریحی

به طور معمول، زمانی که کاربر درخواستی به سرور ارسال می‌کند، باید منتظر بماند تا تمام عملیات انجام شود و سپس پاسخ دریافت کند.

اگر یکی از این عملیات چند ثانیه یا حتی چند دقیقه طول بکشد، تجربه کاربری به شدت کاهش پیدا می‌کند.

در چنین شرایطی Celery وظیفه زمان‌بر را به یک Worker ارسال می‌کند و Django بلافاصله پاسخ مناسبی به کاربر برمی‌گرداند. Worker نیز آن عملیات را در پس‌زمینه اجرا می‌کند.

Celery معمولاً در کنار Message Brokerهایی مانند Redis یا RabbitMQ استفاده می‌شود.

مثال

فرض کنید پس از ثبت سفارش، باید یک ایمیل تأیید ارسال شود.

بدون Celery:

• کاربر باید تا پایان ارسال ایمیل منتظر بماند.

با Celery:

• سفارش ثبت می‌شود.

• پاسخ سریع به کاربر نمایش داده می‌شود.

• ارسال ایمیل در پس‌زمینه انجام می‌شود.

اشتباه رایج

یکی از اشتباهات رایج این است که از Celery برای کارهای بسیار ساده و سریع استفاده می‌کنند. استفاده از Celery زمانی ارزشمند است که عملیات واقعاً زمان‌بر باشد.

اشتباه دیگر، تصور این است که Celery جایگزین Django است؛ در حالی که Celery فقط مسئول اجرای وظایف پس‌زمینه است و همچنان منطق اصلی برنامه در Django قرار دارد.

اگر من مصاحبه‌کننده بودم...

بعد از پاسخ شما احتمالاً این سؤال‌ها را نیز مطرح می‌کردم:

• تفاوت اجرای همزمان (Synchronous) و غیرهمزمان (Asynchronous) چیست؟

• Redis در Celery چه نقشی دارد؟

• Worker چیست؟

• اگر Worker متوقف شود چه اتفاقی می‌افتد؟

• آیا می‌توان اجرای یک Task را زمان‌بندی کرد؟

از دید مدرس

یکی از نشانه‌های ورود به پروژه‌های حرفه‌ای، آشنایی با Celery است. تا زمانی که پروژه‌های کوچک می‌نویسید شاید به آن نیازی نداشته باشید، اما در سامانه‌های واقعی مانند فروشگاه‌های اینترنتی، سیستم‌های پیام‌رسان یا پلتفرم‌های آموزشی، انجام بسیاری از عملیات در پس‌زمینه ضروری است تا کاربران پاسخ سریع‌تری دریافت کنند.

۱۴. Django چگونه از حملات CSRF، XSS و SQL Injection جلوگیری می‌کند؟

چرا این سؤال در مصاحبه پرسیده می‌شود؟

امنیت یکی از مهم‌ترین بخش‌های توسعه نرم‌افزار است. مصاحبه‌کننده می‌خواهد مطمئن شود که علاوه بر نوشتن کد، با تهدیدهای امنیتی رایج و قابلیت‌های امنیتی Django نیز آشنا هستید.

پاسخ کوتاه

Django به‌صورت پیش‌فرض مکانیزم‌های امنیتی قدرتمندی برای مقابله با بسیاری از حملات رایج دارد، از جمله:

• CSRF با استفاده از CSRF Token

• XSS با Escape کردن خودکار خروجی Templateها

• SQL Injection با استفاده از Django ORM و Queryهای پارامتری

پاسخ تشریحی

۱. محافظت در برابر CSRF

در فرم‌های HTML، Django یک توکن امنیتی ایجاد می‌کند. هنگام ارسال فرم، این توکن بررسی می‌شود و اگر معتبر نباشد، درخواست رد خواهد شد.

۲. محافظت در برابر XSS

در Templateهای Django، تمام متغیرها به‌صورت خودکار Escape می‌شوند. بنابراین اگر کاربری کد JavaScript وارد کند، مرورگر آن را به‌عنوان متن نمایش می‌دهد و اجرا نمی‌کند.

۳. محافظت در برابر SQL Injection

وقتی از Django ORM استفاده می‌کنید، مقادیر ورودی کاربران مستقیماً داخل Queryهای SQL قرار نمی‌گیرند، بلکه به‌صورت پارامترهای ایمن به پایگاه داده ارسال می‌شوند. به همین دلیل احتمال وقوع SQL Injection تا حد زیادی کاهش می‌یابد.

مثال

استفاده از CSRF Token در فرم:

<form method="post"> {% csrf_token %} ... </form>

استفاده ایمن از ORM:

user = User.objects.get(username=username)

نمونه‌ای از کد ناایمن:

cursor.execute( f"SELECT * FROM auth_user WHERE username='{username}'" )

اشتباه رایج

یکی از رایج‌ترین اشتباهات این است که هنگام استفاده از فرم‌های HTML، تگ {% csrf_token %} را فراموش می‌کنند که در نتیجه با خطای 403 Forbidden مواجه می‌شوند.

اشتباه دیگر، استفاده از SQL خام همراه با الحاق مستقیم ورودی کاربر به Query است که می‌تواند پروژه را در معرض حملات SQL Injection قرار دهد.

همچنین بعضی از توسعه‌دهندگان بدون بررسی، از فیلتر safe در Templateها استفاده می‌کنند و باعث ایجاد آسیب‌پذیری XSS می‌شوند.

اگر من مصاحبه‌کننده بودم...

بعد از پاسخ شما احتمالاً این سؤال‌ها را نیز مطرح می‌کردم:

• تفاوت CSRF و XSS چیست؟

• چه زمانی باید از csrf_exempt استفاده کرد؟

• آیا Django همیشه از SQL Injection جلوگیری می‌کند؟

• فیلتر safe چه کاربردی دارد و چه خطری ایجاد می‌کند؟

• آیا در APIهای REST نیز از CSRF استفاده می‌شود؟

از دید مدرس

یکی از اشتباهاتی که در بین دانشجویان زیاد می‌بینم این است که امنیت را موضوعی مربوط به مراحل پایانی پروژه می‌دانند. در حالی که امنیت باید از اولین روز توسعه در نظر گرفته شود. خوشبختانه Django بسیاری از قابلیت‌های امنیتی را به‌صورت پیش‌فرض در اختیار ما قرار می‌دهد، اما این موضوع به معنی بی‌نیازی از آگاهی برنامه‌نویس نیست. استفاده نادرست از این امکانات می‌تواند همان‌قدر خطرناک باشد که اصلاً از آن‌ها استفاده نکنید.

۱۵. تفاوت استفاده از transaction.atomic() با مدیریت معمولی تراکنش‌ها چیست؟

چرا این سؤال در مصاحبه پرسیده می‌شود؟

این سؤال میزان آشنایی شما با تراکنش‌های پایگاه داده و حفظ یکپارچگی اطلاعات را ارزیابی می‌کند. در پروژه‌های واقعی، بسیاری از عملیات شامل چندین تغییر در دیتابیس هستند و اگر یکی از آن‌ها با خطا مواجه شود، نباید بخشی از اطلاعات ذخیره شود.

پاسخ کوتاه

transaction.atomic() تضمین می‌کند که مجموعه‌ای از عملیات پایگاه داده به‌صورت همه یا هیچ (All or Nothing) اجرا شوند؛ یعنی یا تمام تغییرات ذخیره می‌شوند یا در صورت بروز خطا، همه آن‌ها بازگردانده (Rollback) خواهند شد.

پاسخ تشریحی

فرض کنید هنگام ثبت سفارش باید سه عملیات انجام شود:

1. ایجاد سفارش

2. کاهش موجودی کالا

3. ثبت پرداخت

اگر بعد از ایجاد سفارش، هنگام کاهش موجودی کالا خطایی رخ دهد، نباید سفارش ناقص در پایگاه داده باقی بماند.

با استفاده از transaction.atomic()، Django تمام این عملیات را داخل یک تراکنش اجرا می‌کند. اگر همه مراحل با موفقیت انجام شوند، تغییرات ثبت می‌شوند؛ اما اگر حتی یکی از مراحل با خطا مواجه شود، تمام تغییرات لغو خواهند شد.

این ویژگی باعث حفظ یکپارچگی داده‌ها و جلوگیری از ذخیره اطلاعات ناقص می‌شود.

مثال

from django.db import transaction with transaction.atomic(): order.save() product.stock -= 1 product.save() payment.save()

اگر هنگام اجرای هر یک از این دستورات خطایی رخ دهد، هیچ تغییری در پایگاه داده ذخیره نخواهد شد.

اشتباه رایج

یکی از رایج‌ترین اشتباهات این است که چند عملیات وابسته را بدون استفاده از تراکنش انجام می‌دهند. در نتیجه، اگر یکی از مراحل با خطا متوقف شود، بخشی از اطلاعات در پایگاه داده باقی می‌ماند و داده‌های ناسازگار ایجاد می‌شود.

اشتباه دیگر، قرار دادن عملیات بسیار طولانی یا درخواست‌های شبکه داخل transaction.atomic() است. هرچه مدت زمان باز بودن تراکنش بیشتر باشد، احتمال ایجاد قفل (Lock) روی داده‌ها و کاهش کارایی سیستم افزایش می‌یابد.

اگر من مصاحبه‌کننده بودم...

بعد از پاسخ شما احتمالاً این سؤال‌ها را نیز مطرح می‌کردم:

• تفاوت Commit و Rollback چیست؟

• اگر داخل transaction.atomic() استثنا مدیریت شود، چه اتفاقی می‌افتد؟

• آیا می‌توان چند atomic() تو در تو داشت؟

• چرا نباید تراکنش‌ها بیش از حد طولانی باشند؟

• در چه پروژه‌هایی استفاده از تراکنش ضروری است؟

از دید مدرس

بسیاری از دانشجویان تصور می‌کنند اگر کد بدون خطا اجرا شود، همه چیز درست است. اما در پروژه‌های واقعی، خطا همیشه احتمال دارد. یک برنامه‌نویس حرفه‌ای از همان ابتدا به این فکر می‌کند که اگر اجرای برنامه در میانه راه متوقف شد، آیا اطلاعات پایگاه داده همچنان صحیح و سازگار باقی می‌مانند یا خیر. transaction.atomic() دقیقاً برای حل همین مسئله طراحی شده است.

۱۶. تست‌نویسی در Django را چگونه انجام می‌دهید؟

چرا این سؤال در مصاحبه پرسیده می‌شود؟

این سؤال نشان می‌دهد که آیا فقط کد می‌نویسید یا برای اطمینان از صحت عملکرد آن نیز برنامه دارید. در پروژه‌های حرفه‌ای، تست‌نویسی بخش جدایی‌ناپذیر فرآیند توسعه نرم‌افزار است و نقش مهمی در کاهش خطاها و افزایش کیفیت کد دارد.

پاسخ کوتاه

در Django، تست‌نویسی معمولاً با استفاده از ماژول django.test انجام می‌شود. توسعه‌دهندگان می‌توانند Modelها، Viewها، Formها، APIها و سایر بخش‌های پروژه را به‌صورت خودکار آزمایش کنند.

پاسخ تشریحی

تست‌نویسی به این معناست که قبل یا بعد از نوشتن کد، سناریوهای مختلف برنامه را به‌صورت خودکار بررسی کنیم.

Django هنگام اجرای تست‌ها یک پایگاه داده موقت ایجاد می‌کند تا اطلاعات واقعی پروژه تغییر نکنند.

با استفاده از کلاس TestCase می‌توان وضعیت‌های مختلف را شبیه‌سازی کرد و بررسی نمود که آیا خروجی برنامه مطابق انتظار است یا خیر.

از مهم‌ترین بخش‌هایی که معمولاً تست می‌شوند می‌توان به موارد زیر اشاره کرد:

• Modelها

• Viewها

• Formها

• APIها

• مجوزهای دسترسی (Permissions)

• احراز هویت کاربران

مثال

نمونه‌ای از یک تست ساده:

from django.test import TestCase from .models import BlogPost class BlogPostTest(TestCase): def test_create_post(self): post = BlogPost.objects.create( title="آموزش Django" ) self.assertEqual(post.title, "آموزش Django")

اجرای تست‌ها:

python manage.py test

اشتباه رایج

یکی از رایج‌ترین اشتباهات این است که فقط مسیرهای موفق (Happy Path) تست می‌شوند و شرایط خطا یا ورودی‌های نامعتبر نادیده گرفته می‌شوند.

اشتباه دیگر، وابسته بودن تست‌ها به داده‌های واقعی پایگاه داده است. هر تست باید مستقل باشد و بتواند بدون وابستگی به سایر تست‌ها اجرا شود.

همچنین برخی توسعه‌دهندگان پس از هر تغییر در پروژه، تست‌ها را اجرا نمی‌کنند و متوجه ایجاد خطاهای جدید (Regression) نمی‌شوند.

اگر من مصاحبه‌کننده بودم...

بعد از پاسخ شما احتمالاً این سؤال‌ها را نیز مطرح می‌کردم:

• تفاوت TestCase و SimpleTestCase چیست؟

• چرا Django هنگام تست، پایگاه داده جداگانه ایجاد می‌کند؟

• تفاوت Unit Test و Integration Test چیست؟

• Mock چیست و چه زمانی از آن استفاده می‌شود؟

• مزیت استفاده از pytest-django نسبت به تست‌های پیش‌فرض Django چیست؟

از دید مدرس

یکی از باورهای اشتباه بین برنامه‌نویسان تازه‌کار این است که تست‌نویسی فقط برای پروژه‌های بزرگ لازم است. در حالی که حتی در پروژه‌های کوچک نیز چند تست مناسب می‌تواند ساعت‌ها زمان اشکال‌زدایی را ذخیره کند. هرچه پروژه بزرگ‌تر شود، ارزش تست‌نویسی بیشتر مشخص می‌شود؛ زیرا با اطمینان بیشتری می‌توانید کدها را تغییر دهید، بدون اینکه نگران خراب شدن بخش‌های دیگر برنامه باشید.

۱۷. آیا تجربه کار با Django REST Framework دارید؟

چرا این سؤال در مصاحبه پرسیده می‌شود؟

این سؤال نشان می‌دهد که آیا فقط در توسعه وب‌سایت‌های سنتی تجربه دارید یا می‌توانید APIهای حرفه‌ای نیز طراحی کنید. امروزه بسیاری از پروژه‌ها از اپلیکیشن موبایل، پنل مدیریت، فرانت‌اند React یا Vue استفاده می‌کنند و همه این بخش‌ها از طریق API با Django ارتباط برقرار می‌کنند.

پاسخ کوتاه

Django REST Framework (DRF) یکی از محبوب‌ترین ابزارهای توسعه API در پایتون است که امکاناتی مانند Serializer، Authentication، Permission، Pagination، Filtering و ViewSetها را در اختیار توسعه‌دهندگان قرار می‌دهد.

پاسخ تشریحی

به کمک Django REST Framework می‌توان داده‌های Modelها را به فرمت‌هایی مانند JSON تبدیل کرد و آن‌ها را در اختیار برنامه‌های دیگر قرار داد.

DRF امکانات زیادی را به‌صورت آماده ارائه می‌دهد، از جمله:

• ساخت APIهای REST

• اعتبارسنجی داده‌ها با Serializer

• احراز هویت کاربران (Authentication)

• مدیریت سطح دسترسی (Permission)

• صفحه‌بندی (Pagination)

• جستجو و فیلتر اطلاعات

• تولید APIهای استاندارد و قابل نگهداری

به همین دلیل تقریباً در تمام پروژه‌های مدرن Django از DRF استفاده می‌شود.

مثال

نمونه‌ای از یک Serializer:

class CourseSerializer(serializers.ModelSerializer): class Meta: model = Course fields = "__all__"

نمونه‌ای از یک ViewSet:

class CourseViewSet(ModelViewSet): queryset = Course.objects.all() serializer_class = CourseSerializer

اشتباه رایج

یکی از اشتباهات رایج این است که تصور می‌کنند Django REST Framework فقط برای خروجی گرفتن به صورت JSON است؛ در حالی که قابلیت‌های بسیار بیشتری مانند اعتبارسنجی، احراز هویت، مجوزهای دسترسی، نسخه‌بندی API و صفحه‌بندی را نیز فراهم می‌کند.

اشتباه دیگر، باز گذاشتن APIها بدون تعریف Permission مناسب است. بسیاری از توسعه‌دهندگان تازه‌کار فراموش می‌کنند که API نیز مانند صفحات وب باید از نظر امنیت و سطح دسترسی به‌درستی محافظت شود.

اگر من مصاحبه‌کننده بودم...

بعد از پاسخ شما احتمالاً این سؤال‌ها را نیز مطرح می‌کردم:

• تفاوت APIView و ViewSet چیست؟

• تفاوت Serializer و ModelSerializer چیست؟

• Authentication و Authorization چه تفاوتی دارند؟

• چه روش‌هایی برای Authentication در DRF وجود دارد؟

• JWT چیست و چه مزایایی دارد؟

از دید مدرس

بسیاری از دانشجویان پس از یادگیری Django تصور می‌کنند مسیر یادگیری به پایان رسیده است، اما واقعیت این است که بخش بزرگی از پروژه‌های امروزی API محور هستند. یادگیری Django REST Framework در واقع پلی است بین توسعه وب سنتی و ساخت سرویس‌هایی که توسط اپلیکیشن‌های موبایل، React، Vue، Angular و حتی سایر سرورها استفاده می‌شوند. اگر قصد دارید به یک توسعه‌دهنده حرفه‌ای Django تبدیل شوید، یادگیری DRF یکی از مهم‌ترین گام‌های بعدی شما خواهد بود.

جمع‌بندی

این ۱۷ سؤال بخش بزرگی از مهم‌ترین مباحث Django را پوشش می‌دهند و می‌توانند معیار مناسبی برای سنجش دانش یک برنامه‌نویس Django در مصاحبه‌های استخدامی باشند.

البته در یک مصاحبه حرفه‌ای، صرفاً حفظ کردن پاسخ‌ها کافی نیست. مصاحبه‌کنندگان معمولاً با طرح سؤال‌های تکمیلی، میزان درک مفاهیم، قدرت تحلیل، تجربه عملی و توانایی حل مسئله داوطلب را نیز ارزیابی می‌کنند.

اگر قصد دارید به یک توسعه‌دهنده حرفه‌ای Django تبدیل شوید، پیشنهاد می‌کنیم علاوه بر مطالعه این سؤالات، هر موضوع را به‌صورت عملی در پروژه‌های واقعی تمرین کنید. تجربه پیاده‌سازی، اشکال‌زدایی و بهینه‌سازی پروژه‌ها ارزش بسیار بیشتری از حفظ کردن چند پاسخ تئوری دارد.

همچنین پیشنهاد می‌کنیم برای تسلط کامل بر Django، مباحث مرتبط مانند Python، طراحی پایگاه داده، Git، تست‌نویسی، امنیت، بهینه‌سازی عملکرد و Django REST Framework را نیز به‌صورت عمیق یاد بگیرید. ترکیب این مهارت‌ها شما را به یک توسعه‌دهنده آماده ورود به بازار کار تبدیل خواهد کرد.

قدم بعدی چیست؟

اگر هدف شما استخدام به‌عنوان برنامه‌نویس Django یا اجرای پروژه‌های واقعی است، دانستن پاسخ این ۱۷ سؤال به‌تنهایی کافی نیست. برای موفقیت در بازار کار باید بتوانید این مفاهیم را در پروژه‌های عملی پیاده‌سازی کنید.

در دوره جامع آموزش جنگو مقدماتی و دوره جامع جنگوی پیشرفته، تمام مباحث این مقاله را از پایه تا پیشرفته، همراه با ساخت پروژه‌های واقعی، به‌صورت کاملاً عملی آموزش داده‌ایم. همچنین اگر هنوز در ابتدای مسیر برنامه‌نویسی هستید، پیشنهاد می‌کنیم ابتدا دوره آموزش Python را بگذرانید و سپس وارد دنیای توسعه وب با Django شوید.

اگر علاقه‌مند به یادگیری بیشتر هستید، پیشنهاد می‌کنیم سایر مقالات آموزش Django را نیز مطالعه کنید تا با مباحث پیشرفته‌تر این فریم‌ورک آشنا شوید.