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

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

وصلت إلى نهاية مسار TypeScript. الفكرة الأساسية التي يجب أن تبقى معك: الأنواع تصميم. ليست زخرفة ولا مجرد إسكات compiler. النوع الجيد يصف المجال، يضيّق الاحتمالات، ويجعل التغيير أكثر أماناً. لكن البيانات الخارجية تحتاج تحقق runtime، والاختبارات ما زالت ضرورية للسلوك.

قبل اعتبار كود TypeScript جاهزاً، اسأل: هل strict مفعّل؟ هل any محصور؟ هل استجابات API تمثل الفشل؟ هل unions لها فحص شامل؟ هل public types مستقرة وواضحة؟ هل المنطق المهم قابل للاختبار؟ هذه الأسئلة تحول TypeScript من syntax إلى ممارسة هندسية.

مراجعة نهائية

index.ts

type Result<T> =
  | { ok: true; value: T }
  | { ok: false; error: string };

function readPort(value: unknown): Result<number> {
  if (typeof value !== "string") {
    return { ok: false, error: "port must be a string" };
  }

  const port = Number(value);
  if (!Number.isInteger(port) || port <= 0 || port > 65535) {
    return { ok: false, error: "port must be between 1 and 65535" };
  }

  return { ok: true, value: port };
}

const result = readPort("3000");
console.log(result.ok ? `port=${result.value}` : result.error);

Output:

هذا المثال يجمع unknown, validation, وResult. هذه هي عقلية production.

التحدي الأخير

أكمل الدالة بحيث ترجع ok فقط عندما تكون القيمة "ready".

تحدي — Challenge

type Result = { ok: true; value: string } | { ok: false; error: string };

function checkReady(value: unknown): Result {
  /* TODO: تحقق من value ثم أرجع Result مناسب */
  return { ok: false, error: "todo" }; // أرجع نجاحاً فقط إذا value === "ready" — Return success only for ready
}

const result = checkReady("ready");
console.log(result.ok ? result.value : result.error);

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

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

سؤال — Question

لماذا يستقبل readPort قيمته كـ unknown وليس any؟

لأن any محذوف من الإصدارات الحديثة لأن unknown يمنع أي استخدام قبل تضييق النوع بفحص فعلي، بينما any يسكت المترجم ويؤجل الانفجار لوقت التشغيل لأن unknown أسرع في الترجمة الاثنان متكافئان والاختيار ذوق شخصي

النوع any يطفئ الفحص: كل عملية عليه مسموحة والمترجم صامت حتى ينفجر السطر وقت التشغيل. أما unknown فيقلب المعادلة — لا تستطيع فعل شيء بالقيمة حتى تضيّق نوعها بفحص مثل typeof value !== "string"، تماماً كما فعلت readPort. عند حدود البيانات الخارجية، الإجبار على الفحص هو الميزة لا العبء.

سؤال — Question

ما الذي يجعل إرجاع Result أفضل من throw لفشلٍ متوقع مثل منفذ غير صالح؟

لأن throw بطيء جداً في V8 لأن catch لا يعمل مع الدوال غير المتزامنة لأن الفشل يصبح جزءاً من النوع المُرجَع، فيجبر المترجم كل مستدعٍ على فحص ok قبل الوصول إلى القيمة لأن Result يسجل الأخطاء في اللوج تلقائياً

مع Result، الفشل جزء من توقيع الدالة: المستدعي لا يصل إلى result.value حتى يفحص result.ok — المترجم نفسه يمنعه، لأن الـ union المميز يضيّق بالفحص. أما throw فيجعل الفشل غير مرئي في التوقيع: من ينسى try/catch لا يعرف بخطئه حتى ينهار الإنتاج.

سؤال — Question

كودك strict وany محصور — لماذا ما زالت استجابة الـ API تحتاج فحص runtime مثل الذي في readPort؟

لأن الأنواع تُمحى عند الترجمة ولا تفحص البيانات الحقيقية — النوع يحرس الكود من الكود، والفحص يحرس الكود من العالم الخارجي لأن strict mode يعطّل فحص الشبكة لا تحتاج — تعريف نوع الاستجابة يضمن شكلها القادم من الخادم لأن JSON لا يدعم الأرقام الصحيحة

الأنواع تُمحى عند الترجمة — وقت التشغيل لا يوجد Result ولا number، فقط JavaScript عارية. استجابة API أو ملف إعداد يصلان كبيانات لا يعرف المترجم عنها شيئاً وقت كتابة الكود. لهذا كانت readPort تفحص بـ typeof وNumber.isInteger فعلياً: الأنواع تحرس حدود الكود مع الكود، والفحص الفعلي يحرس حدود الكود مع العالم.

استرجع الآن المفردات نفسها من ذاكرتك — هي أول ما تكتبه في أي مشروع إنتاجي جديد.

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

ما النوع الصحيح لقيمة قادمة من الخارج لا تثق بشكلها بعد؟

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

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

ما خيار tsconfig الذي يفعّل حزمة الفحوص الصارمة كلها ويُفترض أن يكون أول ما يُضبط؟

"strict": true في tsconfig.json يفعّل حزمة الفحوص الصارمة دفعة واحدة — noImplicitAny وstrictNullChecks وأخواتها. هو أول سطر يُضبط في مشروع جديد؛ تفعيله لاحقاً على كود قائم أضعاف كلفة البدء به.

ماذا بعد؟

استخدم TypeScript في مشاريع حقيقية صغيرة: CLI، واجهة نموذج، أو API client. ابدأ بـstrict، اكتب types من المجال، وتجنب any إلا عند الحدود وبسبب واضح. عندما تشعر أن النوع صار معقداً جداً، لا تستسلم له؛ ارجع إلى التصميم. غالباً المشكلة ليست في TypeScript، بل في نموذج يحتاج اسماً أو فصلاً أو حالة أوضح.