لماذا تستخدم TypeScript؟ بناء واجهة بيانات أكثر أماناً

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

الفكرة الأساسية

تصف interface أو type شكل قيمة يتعامل معها البرنامج. تمنع TypeScript تمرير كائن يفتقد خاصية مطلوبة أو إرسال نص إلى دالة تتوقع رقماً. الأنواع تختفي بعد الترجمة، لذلك لا تتحقق وحدها من JSON الذي يأتي من الشبكة. يجب فحص البيانات الخارجية وقت التشغيل، ثم تحويلها إلى نوع موثوق. تساعد الخصائص الاختيارية على التعبير عن حالات حقيقية، لكن الإفراط في استخدام any يلغي الفائدة. استخدم unknown عند قراءة قيمة غير معروفة ثم تحقق منها.

مثال برمجي عملي

type OrderItem = {
  name: string;
  unitPrice: number;
  quantity: number;
};

type OrderSummary = {
  subtotal: number;
  itemCount: number;
  note?: string;
};

function summarizeOrder(items: OrderItem[]): OrderSummary {
  const subtotal = items.reduce(
    (total, item) => total + item.unitPrice * item.quantity,
    0
  );

  return {
    subtotal: Math.round(subtotal * 100) / 100,
    itemCount: items.reduce((count, item) => count + item.quantity, 0)
  };
}

const summary = summarizeOrder([
  { name: "كتاب", unitPrice: 12, quantity: 2 },
  { name: "قلم", unitPrice: 2.5, quantity: 3 }
]);

شرح المثال

يحدد OrderItem الحقول المطلوبة لكل عنصر، لذلك يعطي المترجم خطأ إذا نسيت quantity أو كتبت unitPrice كنص. تعيد summarizeOrder كائناً يطابق OrderSummary، بينما note اختيارية لأن الملخص قد لا يحتاج ملاحظة. لا تثبت الأنواع أن السعر موجب أو أن الاسم غير فارغ؛ هذه قواعد يجب فحصها في وقت التشغيل. عند وصول JSON، ابدأ بـ unknown ثم تحقق من الحقول، ولا تستخدم as OrderItem لمجرد إسكات المترجم.

اكتب الأنواع حول البيانات التي تشكل اتفاقاً بين أجزاء التطبيق، مثل استجابة API أو نموذج قاعدة البيانات. اترك الأنواع المحلية البسيطة للاستدلال التلقائي عندما يكون واضحاً. شغل tsc في عملية البناء حتى لا يدخل خطأ نوعي إلى الفرع الرئيسي. عندما تتغير استجابة الخادم، عدل النوع والاختبارات معاً. راجع استخدام any، فظهوره المستمر قد يعني أن الحدود بين البيانات غير الموثوقة والمنطق الداخلي غير واضحة.

طريقة العمل قبل كتابة الكود

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

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

اختبار المثال في حالات مختلفة

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

تحقق من المدخلات قبل استخدامها في الحساب أو التخزين.
أعد رسالة مفهومة ورمزاً مناسباً عند وقوع الخطأ.
اجعل الاختبارات قابلة للإعادة من دون اعتماد على شبكة أو وقت متغير.
راجع أثر التغيير على الأجزاء التي تستدعي الدالة أو المكون.

ملاحظات تتعلق بجودة الكود

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

احتفظ بالإعدادات التي تختلف بين جهاز وآخر خارج الكود، ولا تضع كلمات مرور أو مفاتيح خاصة في المستودع. استخدم سجلات مناسبة أثناء التطوير، ثم راجع ما ينبغي حجبه في بيئة التشغيل. إذا تعامل البرنامج مع بيانات المستخدم، فافصل بين ما يحتاجه التطبيق وما يمكن الاحتفاظ به. هذه الممارسات لا تخص لغة واحدة، بل تقلل المشكلات عندما يكبر المشروع أو يعمل عليه أكثر من شخص.

متى تعرف أن الحل يحتاج إلى تطوير؟

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

إذا وجدت أن الخطأ يتكرر في أكثر من مكان، فابحث عن قاعدة مشتركة. وإذا أصبح التعديل في ملف صغير يؤثر في ملفات كثيرة، فراجع حدود المسؤوليات. لا توجد بنية واحدة صحيحة لكل مشروع، لكن توجد أسئلة تساعدك على اختيار بنية مناسبة: من يملك البيانات؟ من يغيرها؟ ماذا يحدث عند الفشل؟ وكيف يمكن اختبار الجزء من دون تشغيل النظام كله؟

أخطاء ينبغي تجنبها

من الأخطاء كتابة نوع يكرر نفسه في ملفات كثيرة، أو جعل كل خاصية اختيارية حتى يختفي معنى البيانات. لا تخلط بين interface وclass؛ الأولى وصف وقت الترجمة، والثانية كود ينفذ وقت التشغيل. لا تثق في type assertion بعد قراءة الشبكة، ولا تجعل generics معقدة لدرجة يصعب فهمها. النوع الجيد هو الذي يمنع خطأ محتمل ويشرح قراراً، وليس الذي يملأ الشاشة بعلامات.

خطوة تالية مناسبة

أضف دالة type guard للتحقق من استجابة JSON، ثم استخدم union types للحالات مثل loading وsuccess وerror. تعلم utility types مثل Pick وPartial عندما يكون استخدامها أوضح من إعادة تعريف الكائن. بعد ذلك راجع إعدادات tsconfig وفعّل strict تدريجياً، لأن الصرامة تزيد قيمة النظام إذا أصلحت الأخطاء الناتجة عنها بدلاً من تجاهلها.

اعتمد التدرج في إدخال TypeScript

ليس ضرورياً تحويل مشروع JavaScript كاملاً في يوم واحد. ابدأ بملف جديد أو بوحدة صغيرة كثيرة الأخطاء، ثم فعّل قواعد التحقق المناسبة. عرّف أنواع البيانات القادمة من API، لأن الحدود بين الخادم والواجهة هي أكثر الأماكن التي تظهر فيها المفاجآت. لا تستخدم any لإسكات كل رسالة؛ استخدم unknown عندما لا تعرف النوع، ثم افحص القيمة قبل استعمالها. وفي المقابل، لا تجعل الأنواع معقدة إلى درجة تعيق القراءة. TypeScript أداة تساعد الفريق على التعبير عن الافتراضات، وليست بديلاً عن الاختبار أو التحقق من البيانات في وقت التشغيل.

الخلاصة

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

تعديل المقال

إيفلون

لماذا تستخدم TypeScript؟ بناء واجهة بيانات أكثر أماناً