اصل انیشتین: چرا حفظ کردن، مهارت نیست؟
روایت معروفی وجود دارد که از آلبرت انیشتین سرعت نور را پرسیدند و او در پاسخ گفت: «نمی‌دانم. چرا باید چیزی را حفظ کنم که می‌توانم در عرض چند ثانیه در کتاب پیدا کنم؟»

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

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

این رویکرد اغلب به دلایل زیر در مصاحبه‌ها باب شده است:

سنجش آسان: پرسیدن سوالات تعریفی، راهی ساده برای «نمره دادن» و فیلتر کردن سریع کاندیداهاست. پاسخ یا درست است یا غلط و نیازی به تحلیل عمیق ندارد.

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

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

۱. سوالات مبتنی بر «تجربه» بپرسید، نه «تعریف»
به جای اینکه بپرسید: «حرف D در SOLID چیست؟»
بپرسید: «می‌توانی پروژه‌ای را مثال بزنی که در آن از اصل Dependency Inversion استفاده کردی؟ چه مشکلی را برایت حل کرد و اگر استفاده نمی‌کردی چه اتفاقی می‌افتاد؟»

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

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

این روش، توانایی جستجو، یادگیری، و مهم‌تر از همه، رویکرد او به حل مسئله را آشکار می‌کند که در کار روزمره هزاران بار ارزشمندتر از حفظ بودن یک الگوریتم است.

سخن پایانی: مغز را استخدام کنید، نه هارد دیسک را
هدف ما از استخدام، پیدا کردن یک مغز متفکر و حل‌کننده مسئله است، نه یک دایرةالمعارف متحرک.

✍🏻 sina khaghani

وات ایز F() expressions در جنگو 😁

جنگو در مورد تابع F توی داکیومنت میگه:

An F() object represents the value of a model field, transformed value of a model field, or annotated column. It makes it possible to refer to model field values and perform database operations using them without actually having to pull them out of the database into Python memory.
Django uses the F() object to generate an SQL expression that describes the required operation at the database level.

آخرش چی گفته؟ database level

این تابع برای مواقعی به درد میخوره که ممکنه همزمانی یا Concurrency پیش بیاد.
مثلا یه جایی میخواییم از انبار یه محصول کم کنیم، همزمان یه ریکوئست دیگه میاد که اونم میخواد کم کنه.
حالت عادی و بدون استفاده از F ، چون آبجکت توی مموری اومده و مثلا مقدار انبار 10 هست، هر دو از آبجکت توی مموری کم میکنن،
لذا انبار 9 میشه 😳
ولی با F مستقیم آپدیت روی رکورد زده میشه.

پیچوندمش؟ 😅 یه مثال:

فرض کن یه مدل داریم:

class Product(models.Model):
    name = models.CharField(max_length=100)
    stock = models.IntegerField(default=0)

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

product = Product.objects.get(id=1)
product.stock = product.stock - 1
product.save()

مشکل:
اگر دو درخواست هم‌زمان این کار رو بکنن، ممکنه هر دو یک مقدار قدیمی بخونن (مثلاً stock=10) و بعد از save، نتیجه بشه stock=9، در حالی که باید 8 می‌شد!
این همون مشکل همزمانی (Concurrency ) هست.

با F اینجوری میشه:

from django.db.models import F

Product.objects.filter(id=1).update(stock=F('stock') - 1)

اینجا F('stock') به دیتابیس می‌گه:
«به جای اینکه مقدار stock رو بیارم تو پایتون و دوباره بنویسم، مستقیماً در سطح دیتابیس مقدار فیلد رو یکی کم کن.»

این کار باعث می‌شه اتمیک (atomic) باشه و نیازی به lock دستی یا نگرانی از race condition نباشه.

راستی این lock باعث Deadlock نمیشه.
چون Deadlock وقتی پیش میاد که دو یا چند تراکنش هم‌زمان قفل منابع مختلف رو بگیرن و هرکدوم منتظر آزاد شدن قفل اونوری بمونن.

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

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

1️⃣ Round Robin
درخواست‌ها یکی‌ یکی و به ترتیب بین سرورها تقسیم میشن. ساده و رایج هست، ولی توان سرورها رو در نظر نمی‌گیره.

2️⃣ Weighted Round Robin
همون Round Robin ولی سرورهای قوی‌تر درخواست‌ های بیشتری می‌گیرن. اینطوری فشار متعادل‌ تر پخش میشه.

3️⃣ Least Connections
هر درخواست جدید به سروری میره که کمترین Connection فعال رو داره. برای کارهایی که زمان پردازش متغیر دارن خیلی خوبه.

4️⃣ IP Hash
این روش میاد IP کاربر رو هش می‌کنه و توی رنج تعداد سرور ها میزاره مثلا۱۰ تا سرور داریم میشه ۱ تا ۱۰ و request های یک IP همیشه به یه سرور میرن . این روش برای Session ها یا وب‌ اپلیکیشن‌ هایی که state دارن مفیده.

5️⃣ Least Response Time
درخواست‌ها به سمتی میرن که هم تعداد Connection کمتر باشه و هم response time سریع‌ تر. مناسب برای سرویس‌های حساس به Performance.