يا جماعة الخير، السلام عليكم ورحمة الله. معكم أخوكم أبو عمر.
بتذكر مرة، قبل سنوات، كنت بشتغل على مشروع نظام تجارة إلكترونية كبير. كان في عندي دالة (function) رئيسية اسمها processOrder، يعني “معالجة الطلب”. يا ساتر! هاي الدالة كانت كابوسي الليلي. عشان تعالج الطلب، لازم تتأكد من ألف شغلة: هل المستخدم مسجل دخوله؟ هل سلة المشتريات فيها منتجات؟ هل رصيد المستخدم بكفي؟ هل المنتجات متوفرة في المخزون؟ هل عنوان الشحن صحيح؟
الكود كان عبارة عن هرم فرعوني مقلوب من جمل if المتداخلة. كل شرط كان يفتح قوسًا جديدًا، وكنت أغوص أعمق وأعمق في الكود. لما كان يصير عندي خطأ (bug)، كنت أقضي ساعات بس عشان أعرف أنا بأي فرع من فروع هاي الشجرة الملعونة. وصلت لمرحلة كنت أخاف أفتح ملف الكود هاد. كنت أحكي لحالي: “أكيد في طريقة أحسن من هيك! مش معقول المبرمجين الكبار بكتبوا كود بهالتعقيد!”.
ومن يومها، بدأت رحلة البحث عن “الكود النظيف”، وهناك اكتشفت المفهوم اللي أنقذني حرفيًا: شروط الحماية (Guard Clauses). خلوني أحكيلكم كيف هالشغلة البسيطة غيرت كل إشي.
ما هو “هرم الشروط اللعين” (The Pyramid of Doom)؟
قبل ما نحكي عن الحل، خلينا نوصف المشكلة بوضوح. هرم الشروط، أو كما يحلو للبعض تسميته “الكود المتشعب”، هو أسلوب برمجي ينتج عن استخدام جمل if-else متداخلة بكثرة للتحقق من سلسلة من الشروط قبل تنفيذ المنطق الأساسي للدالة.
المشكلة في هذا الأسلوب تكمن في عدة نقاط:
- صعوبة القراءة: كل مستوى تداخل جديد يزيد من الحمل المعرفي (Cognitive Load) على المبرمج. عقلك يحتاج لتتبع كل المسارات الممكنة ليفهم ماذا يفعل الكود.
- صعوبة التعديل: إضافة شرط جديد أو تعديل شرط قائم يصبح كابوسًا. قد تنسى قوسًا، أو تضع الكود في المكان الخطأ، مما يؤدي إلى أخطاء منطقية يصعب اكتشافها.
- المنطق الأساسي مدفون: الكود المهم الذي تريد للدالة أن تنفذه (The “happy path”) يكون عادةً في أعمق نقطة في الهرم، محاطًا بعشرات الشروط التي قد لا تتحقق.
مثال قبل التعديل: الكود الهرمي
لنتخيل دالة بسيطة للتحقق من صلاحية تعليق مستخدم قبل حفظه في قاعدة البيانات. انظروا إلى هذا الهرم الجميل:
function saveComment(user, commentText) {
if (user) {
if (user.isLoggedIn) {
if (user.isVerified) {
if (commentText) {
if (commentText.length > 10 && commentText.length < 500) {
// ✅ وأخيراً، وصلنا للمنطق الأساسي!
console.log("جاري حفظ التعليق...");
db.save(commentText);
return { success: true, message: "تم حفظ التعليق بنجاح" };
} else {
return { success: false, message: "طول التعليق غير مناسب" };
}
} else {
return { success: false, message: "التعليق فارغ" };
}
} else {
return { success: false, message: "حساب المستخدم غير موثق" };
}
} else {
return { success: false, message: "يجب تسجيل الدخول أولاً" };
}
} else {
return { success: false, message: "المستخدم غير موجود" };
}
}
شايفين المأساة؟ المنطق الأساسي، وهو سطر واحد لحفظ التعليق، مدفون في 5 مستويات من التداخل. قراءته متعبة، وتعديله مرعب.
الحل السحري: شروط الحماية (Guard Clauses)
شروط الحماية هي تقنية بسيطة جدًا تقوم على مبدأ “اخرج مبكرًا” أو “Fail Fast”. بدلاً من التحقق من الشرط الإيجابي وتكملة الكود داخله، نقوم بالتحقق من الشرط السلبي والخروج من الدالة فورًا إذا لم يتحقق.
بهذه الطريقة، أنت تقوم بتنظيف كل الحالات الشاذة أو غير الصالحة في بداية الدالة. وما يتبقى بعد هذه “الحماية” هو المسار الرئيسي النظيف والواضح (The happy path) بدون أي تداخل.
“مبدأ شروط الحماية: تعامل مع الحالات الاستثنائية أولاً، ثم اترك المسار الرئيسي واضحًا ومسطحًا.”
مثال بعد التعديل: الكود المسطح الجميل
الآن، دعونا نعيد كتابة نفس الدالة السابقة باستخدام شروط الحماية. انظروا إلى الفرق الشاسع في الوضوح والبساطة:
function saveCommentWithGuards(user, commentText) {
// الحارس الأول: هل المستخدم موجود؟
if (!user) {
return { success: false, message: "المستخدم غير موجود" };
}
// الحارس الثاني: هل المستخدم مسجل دخوله؟
if (!user.isLoggedIn) {
return { success: false, message: "يجب تسجيل الدخول أولاً" };
}
// الحارس الثالث: هل حساب المستخدم موثق؟
if (!user.isVerified) {
return { success: false, message: "حساب المستخدم غير موثق" };
}
// الحارس الرابع: هل التعليق فارغ؟
if (!commentText) {
return { success: false, message: "التعليق فارغ" };
}
// الحارس الخامس: هل طول التعليق مناسب؟
if (commentText.length = 500) {
return { success: false, message: "طول التعليق غير مناسب" };
}
// ✅ المسار الرئيسي (Happy Path) واضح تماماً وبدون أي تداخل
console.log("جاري حفظ التعليق...");
db.save(commentText);
return { success: true, message: "تم حفظ التعليق بنجاح" };
}
سبحان الله! نفس المنطق تمامًا، لكن الفرق في المقروئية هائل. الكود أصبح مسطحًا (flat)، وكل شرط أصبح واضحًا ومستقلاً بذاته. المنطق الأساسي للدالة يظهر في النهاية بشكل جليّ، وهذا هو المطلوب.
نصائح أبو عمر الذهبية 💡
من خبرتي في هذا المجال، تعلمت بعض الأمور عن استخدام شروط الحماية، وأحب أن أشارككم إياها:
1. اجعلها القاعدة، لا الاستثناء
عندما تبدأ بكتابة دالة جديدة، فكر دائمًا بأسلوب شروط الحماية. ما هي الشروط المسبقة (Pre-conditions) التي يجب أن تكون صحيحة؟ تحقق من عكسها واخرج من الدالة إذا لم تتحقق. اجعل هذا هو أسلوبك الافتراضي في التفكير.
2. ليست كل جملة `if` عدوًا
صحيح أننا ننتقد التداخل، لكن هذا لا يعني أن جملة if-else سيئة دائمًا. إذا كان لديك مساران منطقيان متساويان في الأهمية، فإن استخدام if-else قد يكون أوضح.
مثال:
// هنا، كلا المسارين مهمان بنفس القدر
if (user.role === 'admin') {
showAdminDashboard();
} else {
showUserDashboard();
}
في هذه الحالة، استخدام شرط حماية سيكون غريبًا وغير منطقي. شروط الحماية تتألق عندما تتعامل مع التحقق من الصحة (Validation) والحالات الشاذة (Edge Cases).
3. إعادة الهيكلة (Refactoring) متعة!
هل لديك قاعدة كود قديمة مليئة بالأهرامات؟ لا تخف! إعادة هيكلة هذه الدوال باستخدام شروط الحماية هي من أمتع المهام وأكثرها إرضاءً للمبرمج. اختر دالة واحدة معقدة كل يوم، وحولها إلى كود مسطح ونظيف. ستشعر بإنجاز رائع، وستجعل حياة زملائك (ونفسك في المستقبل) أسهل بكثير.
4. اجمع الشروط المتشابهة
إذا كان لديك عدة شروط حماية تتعلق بنفس الموضوع، يمكنك أحيانًا دمجها في شرط واحد لتكون أوضح. فمثلاً، في مثالنا السابق، بدلًا من التحقق من الطول الأدنى والأقصى كل على حدة، دمجناهما في شرط واحد باستخدام || (OR)، مما جعل الكود أقصر وأوضح.
الخلاصة: اكتب كودًا يحبه زملاؤك (ونفسك المستقبلية)
في النهاية يا إخوان، البرمجة ليست فقط عن جعل الكمبيوتر يفهم ما نريد، بل هي أيضًا عن كتابة كود يستطيع البشر قراءته وصيانته بسهولة. هرم الشروط المتداخلة هو عدو المقروئية الأول، وشروط الحماية (Guard Clauses) هي السلاح الفعال والبسيط للقضاء عليه.
في المرة القادمة التي تجد نفسك تكتب if داخل if، توقف لحظة واسأل نفسك: “هل يمكنني قلب المنطق واستخدام شرط حماية للخروج المبكر؟”. في 90% من الحالات، ستكون الإجابة نعم، وستكون النتيجة كودًا أنظف، أوضح، وأكثر احترافية.
تذكر دائمًا، اكتب الكود الذي تتمنى أن تقرأه. والله يوفق الجميع. 🙏
