شفرتنا كانت غابة من جمل if-else: كيف أنقذتنا ‘جداول البحث’ (Lookup Tables) من جحيم المنطق المتشعب؟

يا جماعة الخير، السلام عليكم ورحمة الله.

اسمحولي اليوم أحكيلكم قصة صارت معي قبل كم سنة، قصة بتوجّع القلب وبتعلّم بنفس الوقت. كنا شغالين على نظام إدارة محتوى كبير، نظام فيه صلاحيات مستخدمين معقدة شوي: فيه المدير (Admin)، والمحرر (Editor)، والكاتب (Author)، والمراجع (Reviewer)، والزائر (Visitor)… والقائمة تطول. في بداية المشروع، الأمور كانت بسيطة، “إذا كان المستخدم مدير، أعطه كل الصلاحيات، وإلا…”، وهكذا.

مع الوقت، كبر النظام وصار وحش. كل طلب جديد من العميل كان معناه إضافة else if جديدة في قلب الكود. وصلت لمرحلة، والله العظيم، إنه الملف المسؤول عن تحديد الصلاحيات صار أطول من قائمة مشتريات ست الحجة قبل العيد. صرت أخاف أفتح الملف! كل تعديل بسيط بياخد ساعات من الخوف والترقب، وبنقعد نعمل اختبارات مكثفة بس عشان نتأكد إنه ما خربنا إشي ثاني بالغلط. كان الكود عبارة عن غابة، أو زي ما بحب أسميها “جحيم المنطق المتشعب”.

في يوم من الأيام، كنت قاعد مع فنجان القهوة الصباحي، وبحاول أضيف صلاحية جديدة للمراجع، ولقيت حالي ضايع بين عشرات الـ if المتداخلة. وقتها قلت لحالي: “يا أبو عمر، لهون وبس! لازم نلاقي حل جذري. الشغلانة هاي مش لازم تكون هيك”. ومن هنا بدأت رحلة البحث عن الخلاص، وكان الخلاص على يد بطل بسيط اسمه “جدول البحث” أو الـ Lookup Table.

الكارثة: ما هي مشكلة غابة الـ if-else؟

خلونا نكون صريحين، كلنا بنستخدم جمل if-else أو switch، وهي جزء أساسي من أي لغة برمجة. لكن المشكلة تبدأ عندما تتحول من أداة مفيدة إلى وحش يلتهم مقروئية الكود وسهولة صيانته.

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

function getPermissions(role) {
  if (role === 'admin') {
    return ['create', 'read', 'update', 'delete', 'publish', 'manage_users'];
  } else if (role === 'editor') {
    return ['create', 'read', 'update', 'publish'];
  } else if (role === 'author') {
    return ['create', 'read', 'update'];
  } else if (role === 'reviewer') {
    return ['read', 'approve_content'];
  } else if (role === 'visitor') {
    return ['read'];
  } else {
    // الحالة الافتراضية
    return [];
  }
}

للوهلة الأولى، قد يبدو الكود منطقياً. لكن فكروا معي في هذه النقاط:

• صعوبة القراءة: كلما زادت الأدوار، زاد طول الدالة وأصبحت قراءتها وفهمها مهمة شاقة.
• صعوبة الصيانة: ماذا لو أردنا إضافة دور جديد مثل “مساعد محرر” (sub-editor)؟ ستحتاج إلى تعديل الكود نفسه، إضافة else if جديدة، وإعادة اختبار كل شيء. هذا يتعارض مع مبدأ (Open/Closed Principle) الذي يقول أن الكود يجب أن يكون مفتوحًا للإضافة، مغلقًا للتعديل.
• عرضة للأخطاء: مع كل تعديل في منطق الدالة، هناك فرصة لارتكاب خطأ قد يؤثر على جميع الأدوار الأخرى.
• تكرار المنطق: قد تجد نفسك تكرر نفس المنطق في أماكن مختلفة من النظام للتعامل مع هذه الأدوار.

المنقذ: جداول البحث (Lookup Tables)

هنا يأتي دور البطل. جدول البحث هو ببساطة هيكل بيانات (مثل كائن/Object أو خريطة/Map أو حتى مصفوفة/Array) يفصل “البيانات” عن “المنطق”. بدلاً من كتابة منطق معقد لتحديد نتيجة بناءً-على مُدخل، نقوم بتخزين كل المدخلات والنتائج المحتملة في جدول، ثم نستخدم المُدخل كمفتاح للبحث عن النتيجة مباشرة.

الشغلة مش سحر، هي مجرد تنظيم. دعونا نعيد كتابة الدالة السابقة باستخدام جدول بحث.

مثال بعد الإنقاذ: الكود النظيف

سنقوم بإنشاء كائن (Object) بسيط يمثل جدول البحث الخاص بنا، حيث يكون “اسم الدور” هو المفتاح (key)، و”مصفوفة الصلاحيات” هي القيمة (value).

const permissionsByRole = {
  admin: ['create', 'read', 'update', 'delete', 'publish', 'manage_users'],
  editor: ['create', 'read', 'update', 'publish'],
  author: ['create', 'read', 'update'],
  reviewer: ['read', 'approve_content'],
  visitor: ['read'],
};

function getPermissions(role) {
  // ابحث عن الدور في الجدول، وإذا لم تجده، أرجع مصفوفة فارغة
  return permissionsByRole[role] || [];
}

شايفين الفرق؟ يا إلهي على الراحة النفسية! انظروا ماذا كسبنا:

1. مقروئية عالية: الآن، الصلاحيات أصبحت “بيانات” واضحة ومرتبة. يمكنك أن ترى جميع الأدوار وصلاحياتها في مكان واحد وبنظرة واحدة.
2. صيانة سهلة جدًا: هل تريد إضافة دور “مساعد محرر”؟ ببساطة أضف سطراً جديداً إلى كائن permissionsByRole. أنت لا تلمس منطق الدالة على الإطلاق!

   
   const permissionsByRole = {
     // ... الأدوار السابقة
     'sub-editor': ['read', 'update_drafts'],
   };
       

3. قابلية للتوسع: يمكنك إضافة مئة دور جديد، والدالة getPermissions ستبقى كما هي، سطر واحد من الكود.
4. فصل الاهتمامات (Separation of Concerns): لقد فصلنا “بيانات الصلاحيات” عن “منطق الحصول على الصلاحيات”. هذا يجعل الكود أكثر تنظيمًا ويمكن نقل كائن الصلاحيات إلى ملف إعدادات (config) منفصل أو حتى جلبه من قاعدة بيانات.

نصائح عملية من خبرة أبو عمر

على مدار مسيرتي، تعلمت بعض الحيل والنصائح عند التعامل مع جداول البحث، وأحب أن أشارككم إياها:

1. ليس فقط للكائنات (Objects)

جداول البحث يمكن أن تكون أي هيكل بيانات مناسب. في المثال السابق استخدمنا كائنًا، لكن يمكنك استخدام Map إذا كنت تحتاج مفاتيح ليست سلاسل نصية (non-string keys) أو تهتم بترتيب الإدخال. في بعض الحالات، يمكن أن تكون مصفوفة بسيطة هي كل ما تحتاجه.

تخيل أن لديك حالات بناءً على أرقام (0, 1, 2). يمكنك استخدام مصفوفة كجدول بحث: const statuses = ['Pending', 'Approved', 'Rejected']; const statusText = statuses[statusCode];

2. تعامل مع الحالات غير الموجودة (Default Cases)

ماذا يحدث إذا تم تمرير دور غير موجود في جدول البحث؟ في مثالنا، استخدمنا || [] لإرجاع مصفوفة فارغة كقيمة افتراضية. هذا مهم جدًا لتجنب الأخطاء (مثل undefined) وجعل دالتك أكثر قوة ومتانة.

3. عندما يصبح الجدول معقدًا جدًا

في بعض الأحيان، لا تكون القيمة مجرد بيانات بسيطة، بل قد تكون دالة بحد ذاتها! وهذا نمط قوي جدًا يسمى “نمط الإستراتيجية” (Strategy Pattern).

لنفترض أن لكل دور طريقة مختلفة لحساب المكافأة:

// الطريقة القديمة (if-else)
function calculateBonus(employee) {
    if (employee.role === 'manager') {
        return employee.salary * 0.2;
    } else if (employee.role === 'developer') {
        return employee.salary * 0.1;
    } // ... وهكذا
}

// طريقة جدول البحث بالدوال
const bonusStrategies = {
    manager: (salary) => salary * 0.2,
    developer: (salary) => salary * 0.1,
    intern: () => 100, // مكافأة ثابتة
};

function calculateBonus(employee) {
    const strategy = bonusStrategies[employee.role];
    return strategy ? strategy(employee.salary) : 0;
}

هنا، جدول البحث لا يخزن قيمًا، بل يخزن “سلوكيات” (دوال). هذا نمط متقدم وقوي للغاية.

4. لا تفرط في الاستخدام

زي ما بحكوها، “كل شي بزيد عن حده بنقلب ضده”. إذا كان لديك شرطان فقط (if-else بسيطة)، فلا داعي لتعقيد الأمور وإنشاء جدول بحث. استخدم هذه التقنية عندما يكون لديك 3 حالات أو أكثر، أو عندما تتوقع أن هذه الحالات ستزيد في المستقبل. الهدف هو التبسيط وليس التعقيد.

الخلاصة: اكتب كودًا يريحك ويريح من بعدك

في النهاية يا أحباب، البرمجة ليست فقط في كتابة كود يعمل. البرمجة الحقيقية هي كتابة كود واضح، منظم، وسهل الصيانة. الانتقال من غابة if-else إلى جدول بحث منظم ليس مجرد “إعادة هيكلة” (refactoring)، بل هو تغيير في طريقة التفكير: من التفكير في “المنطق والإجراءات” إلى التفكير في “البيانات والعلاقات”.

في المرة القادمة التي تجد فيها نفسك تكتب else if للمرة الثالثة أو الرابعة في نفس الكتلة البرمجية، توقف للحظة. خذ نفسًا عميقًا، اشرب فنجان شاي بالنعناع، واسأل نفسك: “هل يمكن لجدول بحث أن ينقذني من هذا الجحيم؟” في معظم الأحيان، ستكون الإجابة نعم. 👍

كودك هو بيتك الثاني، فحافظ عليه نظيفًا ومرتبًا. صدقني، “أنت” المستقبلي، وزملاؤك في الفريق، سيدعون لك بالخير. بالتوفيق!