ช่วงความสลับซับซ้อนของวัฏจักร [ปิด]

ประเภทของความซับซ้อนตามวัฏจักรคืออะไร? ตัวอย่างเช่น:

1-5: บำรุงรักษาง่าย
6-10: ยาก
11-15: ยากมาก
20+: ใกล้จะเป็นไปไม่ได้

เป็นเวลาหลายปีแล้วที่ฉันได้ไปโดยมีข้อสันนิษฐานว่า 10 ข้อ จำกัด และสิ่งอื่น ๆ นอกเหนือจากนั้นไม่ดี ฉันกำลังวิเคราะห์วิธีแก้ปัญหาและฉันพยายามกำหนดคุณภาพของรหัส ความซับซ้อนตามวัฏจักรแน่นอนไม่ได้วัดเพียง แต่มันสามารถช่วย มีวิธีการที่มีความซับซ้อนของวงจร 200+ ฉันรู้ว่ามันแย่มาก แต่ฉันอยากรู้เกี่ยวกับช่วงล่างเช่นในตัวอย่างด้านบน

ฉันพบสิ่งนี้ :

ค่าอ้างอิงดังกล่าวจาก Carnegie Mellon กำหนดช่วงคร่าวๆสี่ค่าสำหรับค่าความซับซ้อนของวงจร:

• วิธีการระหว่าง 1 ถึง 10 ถือว่าง่ายและเข้าใจง่าย
• ค่าระหว่าง 10 ถึง 20 แสดงถึงรหัสที่ซับซ้อนกว่าซึ่งอาจยังเข้าใจได้ อย่างไรก็ตามการทดสอบจะยากขึ้นเนื่องจากจำนวนสาขาที่เป็นไปได้มากขึ้นที่รหัสสามารถทำได้
• ค่า 20 ขึ้นไปเป็นรหัสทั่วไปที่มีเส้นทางการทำงานที่มีศักยภาพจำนวนมากและสามารถทดสอบและทดสอบได้อย่างเต็มที่ด้วยความยากลำบากและความพยายามอย่างยิ่ง
• วิธีการที่จะสูงขึ้นเช่น> 50 แน่นอนว่าไม่สามารถรักษาได้

เมื่อใช้การวัดรหัสสำหรับโซลูชันผลลัพธ์จะเป็นสีเขียวสำหรับสิ่งใดก็ตามที่ต่ำกว่า 25 ฉันไม่เห็นด้วยกับสิ่งนี้ แต่ฉันหวังว่าจะได้รับอินพุตอื่น ๆ

มีรายการช่วงที่ยอมรับโดยทั่วไปสำหรับความซับซ้อนของวัฏจักรหรือไม่?

ฉันคิดว่ามันขึ้นอยู่กับความสามารถของทีมงานการเขียนโปรแกรมของคุณและส่วนเล็ก ๆ ของความรู้สึกอ่อนไหวของคุณในฐานะผู้จัดการ

โปรแกรมเมอร์บางคนเป็นผู้สนับสนุนอย่างแข็งขันของ TDD และจะไม่เขียนโค้ดใด ๆ โดยไม่ต้องเขียนการทดสอบหน่วยก่อน โปรแกรมเมอร์คนอื่น ๆ สามารถสร้างโปรแกรมที่ไม่มีข้อบกพร่องได้อย่างสมบูรณ์แบบโดยไม่ต้องทำการทดสอบหน่วยเดียว ระดับของความซับซ้อนของวัฏจักรที่แต่ละกลุ่มสามารถทนได้นั้นเกือบจะแตกต่างกันอย่างแน่นอน

มันเป็นตัวชี้วัดส่วนตัว ประเมินการตั้งค่าในโซลูชัน Code Metrics ของคุณและปรับให้เป็นจุดที่คุณรู้สึกสบายใจที่ให้ผลลัพธ์ที่สมเหตุสมผล

ไม่มีหมวดหมู่ที่กำหนดไว้ล่วงหน้าและจะไม่มีการจัดหมวดหมู่ด้วยเหตุผลหลายประการ:

1. เทคนิคการเปลี่ยนโครงสร้างใหม่เพียงแค่ย้ายความซับซ้อนจากจุดหนึ่งไปยังอีกจุดหนึ่ง (ไม่ใช่จากโค้ดของคุณไปยังเฟรมเวิร์กหรือไลบรารีภายนอกที่ผ่านการทดสอบอย่างดี แต่จากตำแหน่งหนึ่งไปยังอีกฐานหนึ่งของโค้ดเบส) มันช่วยลดความซับซ้อนของวงจรและช่วยโน้มน้าวให้เจ้านายของคุณ(หรือบุคคลที่รักการนำเสนอด้วยกราฟิกที่เพิ่มขึ้นอย่างต่อเนื่อง) ที่คุณใช้เวลาในการทำสิ่งที่ยอดเยี่ยม แต่รหัสยังคงแย่เหมือนเดิม

2. ในทางตรงกันข้ามบางครั้งเมื่อคุณปรับโครงสร้างโครงการโดยใช้การออกแบบและรูปแบบการเขียนโปรแกรมบางครั้งความซับซ้อนของวงจรจะแย่ลงในขณะที่รหัส refactored นั้นมีความชัดเจน: นักพัฒนารู้จักรูปแบบการเขียนโปรแกรม ดังนั้นมันจึงทำให้รหัสสำหรับพวกมันง่ายขึ้น แต่ความซับซ้อนตามวัฏจักรไม่ได้นำมาพิจารณาในบัญชี

3. เทคนิคที่ไม่ใช่การรีแฟคเตอร์อื่น ๆ บางอย่างไม่ส่งผลกระทบต่อความซับซ้อนของวงจรในขณะที่ลดความซับซ้อนของรหัสสำหรับนักพัฒนาซอฟต์แวร์ลงอย่างมาก ตัวอย่าง: การเพิ่มความคิดเห็นหรือเอกสารที่เกี่ยวข้อง "การทำให้ทันสมัย" รหัสโดยใช้น้ำตาลประโยค

4. มีบางกรณีที่ความซับซ้อนของวัฏจักรไม่เกี่ยวข้อง ฉันชอบตัวอย่างที่กำหนดโดย whatsisname ในความคิดเห็นของเขา : switchข้อความขนาดใหญ่บางคำสามารถชัดเจนมากและการเขียนใหม่ในแบบ OOPy ที่มากขึ้นจะไม่เป็นประโยชน์มาก ในขณะเดียวกันข้อความเหล่านี้เป็นหายนะความซับซ้อนตามวัฏจักร

5. ดังที่โรเบิร์ตฮาร์วีย์กล่าวไว้ข้างต้นแล้วมันขึ้นอยู่กับทีมของตัวเอง

ในทางปฏิบัติฉันได้เห็นซอร์สโค้ดที่มีความซับซ้อนของวัฏจักร แต่ก็แย่มาก ในขณะเดียวกันฉันได้เห็นรหัสที่มีความซับซ้อนสูง แต่ก็ไม่ได้มีความเจ็บปวดมากเกินไปที่จะเข้าใจมัน

มันเป็นเพียงว่าไม่มีและไม่สามารถเป็นเครื่องมือใด ๆ ซึ่งจะระบุไม่มีที่ติวิธีการที่ดีหรือไม่ดีเป็นชิ้นส่วนที่กำหนดของรหัสหรือวิธีที่ง่ายก็คือการรักษา ในขณะที่คุณไม่สามารถเขียนแอปพลิเคชันซึ่งจะบอกได้ว่าภาพวาดที่กำหนดเป็นผลงานชิ้นเอกและอีกภาพหนึ่งควรถูกโยนทิ้งไปเพราะไม่มีคุณค่าทางศิลปะ

มีตัวชี้วัดที่ใช้งานไม่ได้ (เช่น LOC หรือจำนวนความคิดเห็นต่อไฟล์) และมีตัวชี้วัดที่สามารถให้คำแนะนำแบบดิบ (เช่นจำนวนข้อบกพร่องหรือความซับซ้อนของวงจร) ในทุกกรณีสิ่งเหล่านี้เป็นเพียงคำแนะนำและควรใช้ด้วยความระมัดระวัง