البحث عن توضيحات حول هيكلة التعليمات البرمجية لتقليل التعقيد السيكلوماتي

Question

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

لقد قرأت أنه يمكن حساب CC بشكل غير رسمي على أنه 1 + عدد نقاط القرار في الوظيفة (على سبيل المثال.عبارة if أو for Loop أو Select وما إلى ذلك)، أو أيضًا عدد المسارات عبر دالة...

أدرك أن أسهل طريقة لتقليل CC هي استخدام إعادة هيكلة طريقة الاستخراج بشكل متكرر ...

هناك أشياء لست متأكدًا منها، على سبيل المثال.ما هو CC لأجزاء التعليمات البرمجية التالية؟

1)

for (int i = 0; i < 3; i++)
    Console.WriteLine("Hello");

و

Console.WriteLine("Hello");
Console.WriteLine("Hello");
Console.WriteLine("Hello");

كلاهما يفعلان نفس الشيء، ولكن هل يحتوي الإصدار الأول على نسخة أعلى بسبب عبارة for؟

2)

if (condition1)
    if (condition2)
        if (condition 3)
            Console.WriteLine("wibble");

و

if (condition1 && condition2 && condition3)
    Console.WriteLine("wibble");

بافتراض أن اللغة تقوم بتقييم الدائرة القصيرة، مثل C#، فإن هاتين الجزأتين من التعليمات البرمجية لهما نفس التأثير...ولكن هل CC للجزء الأول أعلى لأنه يحتوي على 3 نقاط قرار/إذا كانت البيانات؟

3)

if (condition1)
{
    Console.WriteLine("one");

    if (condition2)
        Console.WriteLine("one and two");
}

و

if (condition3)
    Console.WriteLine("fizz");

if (condition4)
    Console.WriteLine("buzz");

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

Answer 1

1. نعم.المثال الأول الخاص بك يحتوي على نقطة قرار والثاني لا يحتوي على نقطة قرار، وبالتالي فإن الأول لديه CC أعلى.
2. نعم، ربما، المثال الأول الخاص بك يحتوي على نقاط قرار متعددة وبالتالي CC أعلى.(انظر أدناه للحصول على التوضيح.)
3. نعم ممكن.من الواضح أن لديهم نفس العدد من نقاط القرار، ولكن هناك طرق مختلفة لحساب CC، وهو ما يعني ...

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

المشكلة الأكبر هي ما ذكره الآخرون، حيث يبدو أن شركتك تركز أكثر على CC بدلاً من التركيز على الكود الذي يقف خلفها.بشكل عام، بالتأكيد، أقل من 5 أمر رائع، وأقل من 10 أمر جيد، وأقل من 20 أمر جيد، ومن 21 إلى 50 يجب أن تكون علامة تحذير، وما فوق 50 يجب أن تكون علامة تحذير كبيرة، لكن هذه أدلة وليست قواعد مطلقة.ربما ينبغي عليك فحص التعليمات البرمجية في إجراء يحتوي على CC أعلى من 50 للتأكد من أنه ليس مجرد كومة ضخمة من التعليمات البرمجية، ولكن ربما يكون هناك سبب محدد لكتابة الإجراء بهذه الطريقة، وهو غير ممكن (لأي عدد من الأسباب) لإعادة هيكلتها.

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

Answer 2

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

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

Answer 3

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

هناك شيئان يجب مراعاتهما هنا:

1. قاعدة رموز كبيرة بما يكفي:في أي مشروع غير تافه، سيكون لديك وظائف ذات قيمة CC عالية جدًا.عالية جدًا لدرجة أنه لا يهم إذا كان CC في أحد الأمثلة الخاصة بك سيكون 2 أو 3.إن الوظيفة التي تحتوي على CC لنفترض أن أكثر من 300 هي بالتأكيد شيء يجب تحليله.لا يهم إذا كان CC هو 301 أو 302.
2. لا تنسى أن تستخدم رأسك.هناك طرق تحتاج إلى العديد من نقاط القرار.في كثير من الأحيان يمكن إعادة هيكلتها بطريقة أو بأخرى للحصول على عدد أقل، ولكن في بعض الأحيان لا يمكنهم ذلك.لا تتبع قاعدة مثل "إعادة صياغة كافة الأساليب باستخدام CC > xy".ألقِ نظرة عليها واستخدم عقلك لتقرر ما يجب فعله.

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

Answer 4

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

ونفس الشيء مع المؤسسة الدولية للعلوم بالسلاسل في المثال 2 - هذا الهيكل يسمح لك أن يكون قرأه الذي سيعدم إذا الوحيد CONDITION1 وCONDITION2 هو الصحيح. هذا هو حالة خاصة وهذا غير ممكن في حالة استخدام &&. وبالتالي فإن سلسلة إذا لديها إمكانات أكبر للحالات الخاصة حتى إذا كنت لا تستخدم هذه في التعليمات البرمجية.

Answer 5

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

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

Answer 6

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

عندما أقوم بمراجعة كود تطبيق موجود، أجد أن التعقيد الدوري هو مقياس "نقطة بداية" مفيد.أول شيء أتحقق منه هو الطرق ذات CC> 10.هذه الأساليب ">10" ليست بالضرورة سيئة.إنهم يزودونني فقط بنقطة بداية لمراجعة الكود.

القواعد العامة عند النظر في رقم CC:

• العلاقة بين CC # و # الاختبارات يجب أن تكون CC# <= #tests
• Refactor لـ CC# فقط إذا زاد من القدرة على الصيانة
• يشير CC فوق 10 غالبًا إلى واحد أو أكثر روائح الكود

Answer 7

[تخرج عن الموضوع] إذا كنت تفضل قراءة على درجة جيد في المقاييس (هل كان J.Spolsky أن قال: "ما يقاس، والحصول على القيام به؟" - وهذا يعني أن يتعرضون لسوء المعاملة مقاييس كثير من الأحيان لا أفترض)، فمن غالبا ما تكون أفضل لاستخدام منطقية اسمه جيدا لاستبدال عبارة شرطية معقدة الخاص بك.

ثم

if (condition1 && condition2 && condition3)
    Console.WriteLine("wibble");

وتصبح

bool/boolean theWeatherIsFine =  condition1 && condition2 && condition3;

if (theWeatherIsFine)
    Console.WriteLine("wibble");

Answer 8

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

وCyclomatic التعقيد ويبدو أن مجرد اختصار الآلي خاص لتقصي يحتمل أن تكون (ولكن ليس بالتأكيد) مقتطفات الشفرة إشكالية. ولكن ليست هي المشكلة الحقيقية التي يتعين حلها واحدة من الاختبار؟ كم عدد حالات الاختبار لا يتطلب رمز؟ إذا CC هو أعلى، ولكن عدد من حالات الاختبار هي نفسها ورمز أنظف، لا تقلق بشأن CC.

1). ليس هناك نقطة اتخاذ القرار هناك. هناك واحد ومسار واحد فقط من خلال برنامج هناك، إلا نتيجة واحدة محتملة مع أي من الروايتين. الأول هو أكثر إيجازا وأفضل، تكون ملعونه Cyclomatic التعقيد.

1 حالة اختبار لكلا

2). وفي كلتا الحالتين، إما كتابة "wibble" أو لم تقم.

و2 حالات الاختبار على حد سواء

و3) أول واحد يمكن أن يؤدي إلى أي شيء، "واحد"، أو "واحد" و "واحد واثنين". 3 مسارات. 2ND واحد يمكن أن يؤدي إلى أي شيء، إما من اثنين، أو كليهما. 4 مسارات.

و3 حالات الاختبار للمرة الأولى 4 حالات الاختبار للمرة الثانية