اختبار الجاهزية للإنتاج

اختبار الجاهزية للإنتاج — Production Readiness Quiz

وصلت للاختبار الختامي للفصل الأخير. هذه التحديات لا تختبر الحفظ — تختبر الفهم. هل تعرف متى تستخدم كل أداة؟ هل تستطيع كتابة كود async صحيح؟ هل تفهم لماذا يفشل threading في مهام CPU-bound؟

اقرأ كل تحدٍ بعناية قبل الكتابة. أخطاء مشتركة ستراها في هذه التحديات هي نفس الأخطاء التي يرتكبها المطورون في بيئات الإنتاج الحقيقية.

التحدي الأول: async صحيح أم خاطئ؟

في هذا التحدي ستكتب دالة async تُشغّل ثلاث مهام بالتوازي وتجمع نتائجها. المطلوب هو استخدام asyncio.gather بشكل صحيح.

تذكر: asyncio.gather تُشغّل كل coroutines في نفس الوقت وتُعيد قائمة بنتائجها بنفس ترتيب المدخلات — حتى لو انتهت بترتيب مختلف.

تحدي — Challenge

import asyncio

# كل دالة تُعيد ضعف المدخل — Each function returns double the input
async def task_a():
    await asyncio.sleep(0)
    return 10

async def task_b():
    await asyncio.sleep(0)
    return 20

async def task_c():
    await asyncio.sleep(0)
    return 30

async def main():
    # شغّل المهام الثلاث بالتوازي واجمع نتائجها
    # Run all three tasks in parallel and collect results
    results = await asyncio.gather(task_a(), task_b(), task_c())
    print(f"النتائج: {list(results)}")
    print(f"المجموع: {sum(results)}")

await main()

التحدي الثاني: اختيار الأداة الصحيحة

أحد أهم قرارات هندسة الأداء: هل أستخدم asyncio أم threading أم multiprocessing؟

في هذا التحدي ستُطبّق قاعدة الاختيار: I/O-bound وغير متزامن → asyncio؛ I/O-bound ومكتبة قديمة → threading؛ CPU-bound → multiprocessing.

لماذا يهم هذا القرار؟ الخيار الخاطئ لا يُحسّن الأداء — بل قد يُبطّئه. threading على مهمة CPU-bound تجعل الخيوط تتنافس على GIL وتُبطئ بعضها.

تحدي — Challenge

# صنّف كل مهمة بالأداة المناسبة
# Classify each task with the appropriate tool

tasks = {
    "web_scraping": "io_async",       # طلبات HTTP كثيرة — Many HTTP requests
    "image_processing": "cpu_heavy",  # معالجة بكسلات — Pixel processing
    "file_upload": "io_blocking",     # مكتبة قديمة blocking — Old blocking library
    "video_encoding": "cpu_heavy",    # تشفير فيديو — Video encoding
    "database_queries": "io_async",   # ORM يدعم async — Async-capable ORM
}

def recommend_tool(task_type):
    if task_type == "io_async":
        return "asyncio"
    elif task_type == "cpu_heavy":
        return "multiprocessing"
    elif task_type == "io_blocking":
        return "threading"
    return "unknown"

for task_name, task_type in tasks.items():
    tool = recommend_tool(task_type)
    print(f"{task_name}: {tool}")

التحدي الثالث: إعداد بيئي آمن

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

لماذا كلاس وليس مجرد متغيرات؟ الكلاس يُعطيك:

مكاناً واحداً لقراءة كل الإعداد (Single Responsibility)
قيماً افتراضية صريحة
التحقق من صحة الإعداد عند بدء التطبيق
قابلية الاختبار (يمكن تمرير قيم مختلفة للاختبارات)

تحدي — Challenge

import os

# تعيين بعض المتغيرات — Set some variables
os.environ["APP_NAME"] = "متجري"
os.environ["PORT"] = "9000"
# DEBUG غير موجود — ستستخدم False كقيمة افتراضية

class AppConfig:
    def __init__(self):
        self.app_name = os.environ.get("APP_NAME", "MyApp")
        self.port = int(os.environ.get("PORT", "8000"))
        self.debug = os.environ.get("DEBUG", "false").lower() == "true"

    @property
    def is_production(self):
        return not self.debug

    def __str__(self):
        return (
            f"APP_NAME={self.app_name}\n"
            f"PORT={self.port}\n"
            f"DEBUG={self.debug}\n"
            f"is_production={self.is_production}"
        )

config = AppConfig()
print(config)

التحدي الرابع: كشف أخطاء async

بعض الأخطاء الأكثر صعوبة في asyncio هي تلك التي لا تُسبّب crash واضح — تجعل البرنامج يعمل لكن ببطء أو بشكل غير صحيح.

في هذا التحدي ستقرأ كوداً به مشكلة وتُصلحه. المشكلة: asyncio.sleep يُعيد coroutine — لا ينتهي وحده دون await.

الخطأ الشائع: نسيان await قبل asyncio.sleep يعني أن البرنامج لا ينتظر فعلاً — ينتقل للسطر التالي فوراً. هذا يُفسد منطق الانتظار بالكامل.

تحدي — Challenge

import asyncio

async def phase(name):
    print(f"المرحلة {name}: بدأت")
    await asyncio.sleep(0)          # انتظر — يجب استخدام await هنا
    print(f"المرحلة {name}: اكتملت")

async def main():
    await phase(1)
    await phase(2)

await main()

التحدي الخامس: requirements.txt وجاهزية الإنتاج

قبل النشر، يجب التحقق من اكتمال الإعداد. دالة الفحص (health check) هي أول ما يُنفَّذ عند بدء التطبيق — تتحقق من وجود كل المتطلبات قبل قبول أي طلب.

في هذا التحدي ستكتب دالة تُولّد محتوى requirements.txt ثم تتحقق من الجاهزية.

لماذا إصدارات محددة؟ flask>=3.0 قد يثبّت أي إصدار مستقبلي يكسر كودك. flask==3.0.2 يضمن أن الإنتاج يشغّل نفس ما اختبرته. هذا ما يعنيه “إنتاج موثوق”.

تحدي — Challenge

import os

os.environ["SECRET_KEY"] = "prod-key-xyz"
os.environ["DATABASE_URL"] = "postgresql://prod-host/db"

# توليد requirements.txt — Generate requirements.txt
packages = [
    ("requests", "2.31.0"),
    ("flask", "3.0.2"),
    ("python-dotenv", "1.0.1"),
]

requirements = "\n".join(f"{pkg}=={ver}" for pkg, ver in packages)
print(requirements)
print("---")

# فحص الجاهزية — Readiness check
required_vars = ["SECRET_KEY", "DATABASE_URL"]
all_present = True

for var in required_vars:
    present = var in os.environ
    print(f"{var}: {'موجود' if present else 'مفقود'}")
    if not present:
        all_present = False

print(f"جاهز للنشر: {'نعم' if all_present else 'لا'}")

مراجعة المفاهيم

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

سؤال — Question

لماذا multiprocessing هو الخيار الوحيد لمهمة CPU-bound مثل تشفير الفيديو؟

لأن asyncio لا يستطيع استدعاء دوال الرياضيات لأن الخيوط في Python أبطأ من العمليات في كل الحالات لأن GIL يمنع الخيوط من استغلال أكثر من نواة، والعمليات المستقلة تتجاوزه بمفسّر لكل عملية لأن threading لا يعمل على أنظمة Linux

قفل GIL يسمح لخيط واحد فقط بتنفيذ Python bytecode في اللحظة الواحدة، فتتنافس الخيوط على القفل في مهمة CPU-bound وتبطئ بعضها. multiprocessing ينشئ عمليات مستقلة لكل منها مفسّرها وGIL خاص بها، فتعمل الأنوية فعلاً بالتوازي. أما asyncio وthreading فمكانهما مهام I/O حيث الانتظار هو العبء لا الحساب.

سؤال — Question

ما نتيجة كتابة asyncio.sleep(1) داخل دالة async بدون await قبلها؟

ينهار البرنامج بخطأ SyntaxError يُنشأ كائن coroutine ولا يُنفَّذ — البرنامج لا ينتظر فعلاً ويستمر فوراً بلا خطأ واضح ينتظر البرنامج ثانية كاملة كالمعتاد يتحول السطر تلقائياً إلى time.sleep

استدعاء coroutine دون await يُنشئ كائن coroutine ولا يشغّله — البرنامج ينتقل للسطر التالي فوراً وكأن الانتظار لم يكن. لا crash ولا رسالة خطأ واضحة (فقط تحذير RuntimeWarning قد لا تلاحظه) — منطق التوقيت كله يفسد بصمت. هذا من أصعب أخطاء asyncio اكتشافاً.

سؤال — Question

لماذا يكتب requirements.txt الإنتاجي flask==3.0.2 بدل flask>=3.0؟

لأن التثبيت يضمن أن الإنتاج يشغّل ما اختبرته بالضبط، و>= يسمح لإصدار كاسر مستقبلي بالتسلل لأن pip لا يدعم صيغة >= لأن الإصدارات الأحدث دائماً أبطأ لأن == يجعل التثبيت أسرع

التثبيت flask==3.0.2 يضمن أن الإنتاج يشغّل الإصدار نفسه الذي اختبرته حرفياً. أما >= فيسمح بأي إصدار مستقبلي — وقد يحمل تغييرات كاسرة تصل إنتاجك قبل أن تراها في التطوير. قابلية إعادة البناء (reproducibility) شرط للنشر الموثوق.

استرجع الآن الأسماء نفسها من ذاكرتك — هي التي ستكتبها في أول ملف async حقيقي.

أكمل الفراغ — Fill in the blank

ما دالة asyncio التي تشغّل عدة coroutines بالتوازي وتجمع نتائجها بترتيب المدخلات؟

asyncio.gather(a(), b(), c()) تشغّل الـ coroutines معاً وتُعيد نتائجها بترتيب المدخلات مهما اختلف ترتيب انتهائها — وهذا ما جعل ناتج التحدي الأول [10, 20, 30] مستقراً.

أكمل الفراغ — Fill in the blank

ما الدالة التي تجمّد حلقة أحداث asyncio بأكملها إذا استُدعيت داخل coroutine؟

time.sleep استدعاء blocking يجمّد الخيط كله — وفي asyncio الخيط الواحد هو كل شيء، فتتوقف معه كل المهام المتزامنة. داخل الكود غير المتزامن استخدم await asyncio.sleep() التي تُعلّق المهمة الحالية وحدها وتترك الحلقة تخدم البقية.

خلاصة الفصل — ما تعلّمته

وصلت للنهاية. إليك خلاصة ما يُمكّنك الآن من فعله:

asyncio: تعرف أن async def تُعرّف coroutine، وawait تُعلّق المهمة الحالية. تعرف أن asyncio.gather يُشغّل مهام I/O-bound بالتوازي في خيط واحد. تعرف أن استخدام time.sleep بدلاً من asyncio.sleep يُجمّد الخيط كله.

threading vs multiprocessing: تعرف أن GIL يمنع تعدد أنوية حقيقية في خيوط Python. تعرف أن threading مفيد للمهام I/O-bound التي تستخدم مكتبات blocking. تعرف أن multiprocessing هو الخيار الوحيد للمهام CPU-bound التي تحتاج أنوية متعددة.

الإنتاج: تعرف كيف تُعرّف الإعداد في متغيرات البيئة لا في الكود. تعرف بناء Dockerfile بسيط لتطبيق Python. تعرف استخدام gunicorn بعمال متعددة بدلاً من خادم التطوير.

مبروك على إتمام مسار Python كاملاً في AzLearn.