شروط الـ if المتداخلة كانت كابوسًا: كيف أنقذتني ‘شروط الحماية’ (Guard Clauses) من جحيم الشيفرة السهمية؟

يا هلا والله بكل المبرمجين والمبرمجات، كيف حالكم يا جماعة؟ معكم أخوكم أبو عمر.

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

كانت الدالة عبارة عن وحش من شروط if المتداخلة. شرط يتحقق من تسجيل دخول المستخدم، وبداخله شرط آخر يتحقق من أن سلة المشتريات ليست فارغة، وبداخله شرط ثالث يتأكد من توفر المنتجات في المخزون، ورابع، وخامس… كان الكود يشبه رأس سهم يشير إلى اليمين، وكلما تعمقت فيه، زاد الصداع والضياع. كنت أتنقل بين أقواس { } كمن يمشي في متاهة لا نهاية لها.

في تلك اللحظة، دخل مديري التقني، رجل خبير وهادئ كنا نناديه “أبو فارس”. نظر إلى شاشتي، ابتسم ابتسامة خفيفة وقال: “شكلك غرقان في بحر الـ if يا أبو عمر. تعال أعلمك كيف تسبح وتطلع لبر الأمان”. تلك الليلة، تعلمت مفهومًا غير حياتي البرمجية: شروط الحماية (Guard Clauses). ومن يومها، أصبحت الشيفرة السهمية عدوي اللدود.

ما هو جحيم الشيفرة السهمية (Arrow Code)؟

قبل أن نغوص في الحل، دعونا نفهم المشكلة جيدًا. “الشيفرة السهمية” أو “Arrow Code” هو مصطلح نصف رسمي نصف ساخر، نطلقه على الشيفرة التي تأخذ شكل رأس السهم بسبب كثرة المسافات البادئة (Indentation) الناتجة عن تداخل الشروط (nested ifs) والحلقات (loops).

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

مثال على الشيفرة السهمية (الكابوس)

تخيل دالة مثل هذه بلغة JavaScript:

function showAdminDashboard(user) {
  if (user) { // هل المستخدم موجود؟
    if (user.isLoggedIn) { // هل سجل دخوله؟
      if (user.role === 'ADMIN') { // هل هو مدير؟
        if (user.hasTwoFactorAuth) { // هل فعّل المصادقة الثنائية؟
          // --- المسار السعيد (Happy Path) ---
          // كل الشروط تحققت، الآن يمكننا عرض لوحة التحكم
          console.log("عرض لوحة تحكم المدير...");
          return { success: true, page: "AdminDashboard" };
        } else {
          console.error("خطأ: يجب تفعيل المصادقة الثنائية.");
          return { success: false, error: "2FA_REQUIRED" };
        }
      } else {
        console.error("خطأ: المستخدم ليس لديه صلاحيات المدير.");
        return { success: false, error: "NOT_AUTHORIZED" };
      }
    } else {
      console.error("خطأ: المستخدم لم يقم بتسجيل الدخول.");
      return { success: false, error: "NOT_LOGGED_IN" };
    }
  } else {
    console.error("خطأ: لا يوجد مستخدم.");
    return { success: false, error: "USER_NOT_FOUND" };
  }
}

هل ترى المشكلة؟

• صعوبة القراءة: عليك أن تتبع بعينك وعقلك كل هذه المستويات لتصل إلى المنطق الأساسي للدالة (عرض لوحة التحكم).
• صعوبة الصيانة: ماذا لو أردت إضافة شرط جديد؟ ستحتاج إلى إضافة مستوى جديد من التداخل، مما يزيد الطين بلة.
• صعوبة التصحيح (Debugging): عندما يحدث خطأ، من الصعب تحديد أي شرط من هذه الشروط هو الذي فشل دون قراءة كل مسارات else.
• التعقيد الحلقي (Cyclomatic Complexity): هذا مصطلح تقني يعني أن هناك مسارات كثيرة محتملة داخل الدالة، وكلما زاد هذا التعقيد، زادت صعوبة اختبار الكود والتأكد من خلوه من الأخطاء.

المنقذ: شروط الحماية (Guard Clauses)

شروط الحماية هي تقنية بسيطة جدًا في مفهومها، لكنها ثورية في تأثيرها. الفكرة الأساسية هي: بدلًا من التحقق من “المسار السعيد” (Happy Path)، تحقق من “المسارات غير السعيدة” (Unhappy Paths) واخرج من الدالة مبكرًا.

بمعنى آخر، في بداية الدالة، ضع “حراسًا” على الباب. كل حارس يتحقق من شرط معين. إذا لم يتحقق الشرط، يمنع الحارس إكمال تنفيذ الدالة ويخرجها فورًا (عبر return أو throw exception).

كيف تعمل شروط الحماية؟

الفلسفة بسيطة:

1. تحقق من شرط مسبق (pre-condition) أو حالة خاطئة.
2. إذا كان الشرط صحيحًا (أي أن الحالة خاطئة)، اخرج من الدالة فورًا.
3. كرر هذه العملية لكل الحالات الخاطئة أو الشاذة في البداية.
4. ما يتبقى من الدالة بعد كل هؤلاء “الحراس” هو المنطق الأساسي، “المسار السعيد”، مكتوبًا بشكل مسطح وواضح دون أي تداخل.

إعادة هيكلة المثال: من السهم إلى الخط المستقيم

الآن، لنأخذ نفس الدالة السابقة ونعيد كتابتها باستخدام شروط الحماية. شاهد السحر وهو يحدث!

function showAdminDashboardWithGuards(user) {
  // الحارس الأول: هل المستخدم موجود أصلاً؟
  if (!user) {
    console.error("خطأ: لا يوجد مستخدم.");
    return { success: false, error: "USER_NOT_FOUND" };
  }

  // الحارس الثاني: هل سجل دخوله؟
  if (!user.isLoggedIn) {
    console.error("خطأ: المستخدم لم يقم بتسجيل الدخول.");
    return { success: false, error: "NOT_LOGGED_IN" };
  }

  // الحارس الثالث: هل هو مدير؟
  if (user.role !== 'ADMIN') {
    console.error("خطأ: المستخدم ليس لديه صلاحيات المدير.");
    return { success: false, error: "NOT_AUTHORIZED" };
  }

  // الحارس الرابع: هل فعّل المصادقة الثنائية؟
  if (!user.hasTwoFactorAuth) {
    console.error("خطأ: يجب تفعيل المصادقة الثنائية.");
    return { success: false, error: "2FA_REQUIRED" };
  }

  // --- المسار السعيد (Happy Path) ---
  // إذا وصلنا إلى هنا، فكل الشروط تحققت. الكود نظيف ومسطح.
  console.log("عرض لوحة تحكم المدير...");
  return { success: true, page: "AdminDashboard" };
}

لاحظ الفرق الشاسع! الكود الآن:

• خطي ومسطح: يقرأ مثل قائمة مهام أو شروط يجب تحقيقها.
• واضح: الشروط المسبقة في الأعلى، والمنطق الرئيسي في الأسفل. لا يوجد تشتيت.
• سهل الصيانة: إضافة شرط جديد هي مجرد إضافة “حارس” جديد في الأعلى دون التأثير على بقية المنطق.
• مبدأ “الفشل السريع” (Fail-Fast): الدالة تفشل وتخرج عند أول مشكلة تواجهها، وهذا يسهل جدًا عملية تصحيح الأخطاء.

“الشيفرة النظيفة يجب أن تُقرأ مثل النثر. يجب أن تكون واضحة ومباشرة، تروي قصة منطق البرنامج دون الحاجة إلى فك ألغاز.” – مقولة أؤمن بها بشدة.

نصائح من أبو عمر (خبرة سنين يا خَال)

مع الوقت، تعلمت بعض الحيل والنصائح لجعل استخدام شروط الحماية أكثر فعالية. اسمحوا لي أن أشارككم “الزبدة”:

1. ابدأ دائمًا بالحالات الشاذة والأساسية

قبل كتابة أي منطق، فكر: ما هي المدخلات التي قد “تكسر” دالتي؟ عادةً ما تكون القيم الفارغة (null أو undefined) أو المدخلات غير الصالحة. تخلص منها في البداية.

function getUsername(user) {
  // حارس ضد القيمة الفارغة
  if (!user) {
    return "زائر";
  }

  // المنطق الرئيسي
  return user.name;
}

2. اجعل رسائل الخروج واضحة

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

3. لا تفرط في استخدامها بشكل خاطئ

شروط الحماية ممتازة للشروط المسبقة (Pre-conditions) والتحقق من المدخلات في بداية الدالة. لا تحاول تحويل كل جملة if/else في منتصف الكود إلى شرط حماية. أحيانًا، يكون استخدام if/else طبيعيًا وضروريًا للتعبير عن منطق متفرع (branching logic) في صلب الدالة.

4. فكر فيها كعقلية وليس مجرد أسلوب

استخدام شروط الحماية هو جزء من عقلية برمجية أكبر تسمى “البرمجة الدفاعية” (Defensive Programming) ومبدأ “الفشل السريع” (Fail-Fast). هذه العقلية تعني أنك تتوقع الأسوأ وتكتب كودًا قادرًا على التعامل معه بأناقة، بدلًا من افتراض أن كل شيء سيكون على ما يرام.

الخلاصة والزبدة 🏁

شروط if المتداخلة هي وصفة أكيدة للصداع، والشيفرة المعقدة، وساعات طويلة من تصحيح الأخطاء. لقد كانت كابوسي الشخصي، وأراهن أنها كابوس الكثيرين منكم.

شروط الحماية (Guard Clauses) هي المنقذ. هي تقنية بسيطة لكنها تغير طريقة تفكيرك وكتابتك للكود. من خلال التحقق من الحالات الخاطئة والخروج المبكر، فإنك:

• تُسطّح هرم الكود وتحوله إلى خط مستقيم.
• تجعل “المسار السعيد” واضحًا وبارزًا.
• تزيد من قابلية القراءة والصيانة بشكل هائل.

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

أتمنى لكم شيفرة نظيفة وخالية من الأسهم! 💪