مراجعة تأثير الشرطية المعقدة

مكتمل

قد تعمل قاعدة التعليمات البرمجية التي تحتوي على شرطيات معقدة بشكل صحيح ، ولكن غالبا ما تختبئ المشكلات تحت السطح مباشرة.

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

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

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

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

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

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

ضع في اعتبارك مثال "رمز السهم" التالي:

// Pseudocode example of deeply nested conditionals ("arrow code")
if (user != null) {
    if (user.IsActive) {
        if (user.Role == "Admin") {
            if (user.HasPermission("View")) {
                Console.WriteLine("Access granted");
            } else {
                Console.WriteLine("Permission denied");
            }
        } else {
            Console.WriteLine("Role not authorized");
        }
    } else {
        Console.WriteLine("User is not active");
    }
} else {
    Console.WriteLine("User not found");
}

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

ملخص

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