Phạm vi phức tạp chu kỳ [đóng]


26

Các loại phức tạp chu kỳ là gì? Ví dụ:

1-5: dễ duy trì
6-10: khó
11-15: rất khó
20+: không thể tiếp cận

Trong nhiều năm nay, tôi đã đi với giả định rằng 10 là giới hạn. Và bất cứ điều gì ngoài đó là xấu. Tôi đang phân tích một giải pháp và tôi đang cố gắng xác định chất lượng của mã. Chắc chắn độ phức tạp chu kỳ không phải là phép đo duy nhất, nhưng nó có thể giúp ích. Có những phương pháp với độ phức tạp chu kỳ là hơn 200. Tôi biết điều đó thật tồi tệ, nhưng tôi tò mò muốn biết về các phạm vi thấp hơn, như trong ví dụ của tôi ở trên.

Tôi tìm thấy điều này :

Các giá trị tham chiếu đã nói ở trên từ Carnegie Mellon xác định bốn phạm vi thô cho các giá trị độ phức tạp chu kỳ:

  • phương pháp từ 1 đến 10 được coi là đơn giản và dễ hiểu
  • các giá trị từ 10 đến 20 chỉ ra mã phức tạp hơn, có thể vẫn dễ hiểu; tuy nhiên việc kiểm tra trở nên khó khăn hơn do số lượng nhánh lớn hơn mà mã có thể thực hiện
  • các giá trị từ 20 trở lên là điển hình của mã với số lượng đường dẫn thực thi tiềm năng rất lớn và chỉ có thể được nắm bắt và kiểm tra đầy đủ với độ khó và nỗ lực rất lớn
  • phương pháp thậm chí còn cao hơn, ví dụ> 50, chắc chắn không thể nhầm lẫn

Khi chạy các số liệu mã cho một giải pháp, kết quả hiển thị màu xanh lá cây cho bất cứ điều gì dưới 25. Tôi không đồng ý với điều này, nhưng tôi đã hy vọng có được đầu vào khác.

Có một danh sách phạm vi thường được chấp nhận cho độ phức tạp chu kỳ?


2
Bạn đã tìm thấy dữ liệu từ Viện Kỹ thuật phần mềm, một tổ chức được công nhận là người dẫn đầu về công nghệ phần mềm. Tôi không hiểu câu hỏi của bạn là gì - bạn đã tìm thấy một danh sách phạm vi cho độ phức tạp theo chu kỳ. Bạn còn tìm kiếm gì nữa?
Thomas Owens

1
Tôi đã thấy nhiều phạm vi khác nhau; đó chỉ là một ví dụ. Và MS hiển thị "màu xanh lá cây" cho bất cứ điều gì dưới 25. Tôi đã tự hỏi nếu có một danh sách phạm vi được chấp nhận. Có lẽ tôi đã tìm thấy nó rồi.
Bob Horn

1
Tôi đồng ý với @ThomasOwens, nhưng tôi vui vì bạn đã hỏi câu hỏi này. Tôi nêu lên nó như là một câu hỏi và một câu trả lời.
Evorlor

1
Trong phiên bản thứ 2 của Hoàn thành mã của Steve McConnell, ông khuyến nghị rằng độ phức tạp theo chu kỳ từ 0 đến 5 thường ổn, nhưng bạn nên lưu ý nếu độ phức tạp bắt đầu trong phạm vi 6 đến 10. Ông giải thích thêm rằng bất cứ điều gì trong độ phức tạp 10, bạn nên cân nhắc mạnh mẽ việc tái cấu trúc mã của mình.
GibboK

Câu trả lời:


19

Tôi cho rằng nó phụ thuộc vào khả năng của nhân viên lập trình của bạn, và một phần không nhỏ vào sự nhạy cảm của bạn với tư cách là người quản lý.

Một số lập trình viên là những người ủng hộ trung thành của TDD, và sẽ không viết bất kỳ mã nào mà không viết bài kiểm tra đơn vị trước. Các lập trình viên khác hoàn toàn có khả năng tạo ra các chương trình hoàn toàn tốt, không có lỗi mà không cần viết một bài kiểm tra đơn vị. Mức độ phức tạp chu kỳ mà mỗi nhóm có thể chịu đựng gần như chắc chắn sẽ thay đổi đáng kể.

Đó là một số liệu chủ quan; đánh giá cài đặt trên giải pháp Mã số liệu của bạn và điều chỉnh nó đến một điểm ngọt ngào mà bạn cảm thấy thoải mái với điều đó mang lại cho bạn kết quả hợp lý.


3
Đồng ý, hơn nữa nó phụ thuộc vào nguyên nhân của sự phức tạp. Một câu lệnh chuyển đổi lớn gọi các chức năng khác, như một phần của máy trạng thái hoặc một cái gì đó tương tự, có thể có độ phức tạp rất cao, mặc dù có thể hầu như không đáng để hiểu.
whatsisname

1
Các tuyên bố chuyển đổi lớn không phải là dấu hiệu của việc thiếu các nguyên tắc OOP, chẳng hạn như đa hình? Máy trạng thái có thể được thực hiện theo cách thanh lịch, với OOP hoặc các mẫu thiết kế. Không?
Bob Horn

3
Đối với một số vấn đề, "sự thanh lịch" là hữu ích, đối với những vấn đề khác, nó chỉ khiến mọi thứ trở nên khó hiểu hơn. Không có viên đạn bạc.
whatsisname

1
-1 Đối với "Các lập trình viên khác hoàn toàn có khả năng tạo ra các chương trình hoàn toàn tốt, không có lỗi mà không cần viết một bài kiểm tra đơn vị." Bạn không thể biết lỗi của nó miễn phí nếu bạn chưa kiểm tra nó.
Sebastien

1
@Sebastien: Việc không có bài kiểm tra đơn vị không có nghĩa là nó không được kiểm tra. Và vâng, nếu bạn đủ tốt, hoàn toàn có thể viết mã không có lỗi mà không cần kiểm tra hoặc kiểm tra khói thô sơ. Phải thừa nhận rằng, những người đó là một giống hiếm.
Robert Harvey

10

Không có danh mục được xác định trước và không thể phân loại vì nhiều lý do:

  1. Một số kỹ thuật tái cấu trúc chỉ di chuyển độ phức tạp từ điểm này sang điểm khác (không phải từ mã của bạn sang khung hoặc thư viện bên ngoài được kiểm tra tốt, mà từ vị trí này sang vị trí khác của cơ sở mã). Nó giúp giảm độ phức tạp theo chu kỳ và giúp thuyết phục sếp của bạn (hoặc bất kỳ người nào yêu thích các bài thuyết trình với đồ họa không ngừng tăng lên) rằng bạn đã dành thời gian để làm một cái gì đó tuyệt vời, nhưng mã vẫn tệ như trước đây.

  2. Ngược lại, đôi khi, khi bạn cấu trúc lại một dự án bằng cách áp dụng một số mẫu thiết kế và lập trình, độ phức tạp theo chu kỳ có thể trở nên tồi tệ hơn, trong khi mã được cấu trúc lại dự kiến ​​sẽ rõ ràng: các nhà phát triển biết các mẫu lập trình (ít nhất là họ dự kiến ​​sẽ biết chúng), vì vậy nó đơn giản hóa mã cho chúng, nhưng độ phức tạp theo chu kỳ không tính đến điều này.

  3. Một số kỹ thuật không tái cấu trúc khác hoàn toàn không ảnh hưởng đến độ phức tạp chu kỳ, trong khi làm giảm nghiêm trọng độ phức tạp của mã cho các nhà phát triển. Ví dụ: thêm ý kiến ​​hoặc tài liệu liên quan. "Hiện đại hóa" mã bằng cách sử dụng đường cú pháp.

  4. Có những trường hợp đơn giản là độ phức tạp chu kỳ là không liên quan. Tôi thích ví dụ được đưa ra bởi whatsisname trong bình luận của anh ấy : một số switchcâu lệnh lớn có thể cực kỳ rõ ràng và viết lại chúng theo cách OOPy hơn sẽ không hữu ích lắm (và sẽ làm phức tạp sự hiểu biết về mã của người mới bắt đầu). Đồng thời, những tuyên bố đó là một thảm họa, phức tạp theo chu kỳ.

  5. Như Robert Harvey đã nói ở trên , nó phụ thuộc vào chính đội.

Trong thực tế, tôi đã thấy mã nguồn có độ phức tạp chu kỳ tốt, nhưng rất tệ. Đồng thời, tôi đã thấy mã có độ phức tạp chu kỳ cao, nhưng tôi không quá đau đớn để hiểu nó.

Chỉ là không có và không thể có bất kỳ công cụ nào có thể chỉ ra, hoàn hảo, mức độ tốt hay xấu của một đoạn mã nhất định hoặc cách dễ dàng duy trì . Vì bạn không thể lập trình một ứng dụng sẽ nói rằng một bức tranh nhất định là một kiệt tác, và một bức tranh khác nên bị vứt đi, bởi vì nó không có giá trị nghệ thuật.

Có những số liệu bị phá vỡ theo thiết kế (như LỘC hoặc số lượng bình luận trên mỗi tệp) và có những số liệu có thể đưa ra một số gợi ý thô (như số lỗi hoặc độ phức tạp theo chu kỳ). Trong mọi trường hợp, đó chỉ là những gợi ý, và nên thận trọng khi sử dụng.


2
+1 Tôi đồng ý với mọi thứ đã nói. Độ phức tạp theo chu kỳ hoặc LỘC chỉ là số liệu được trao cho bạn bằng cách phân tích mã tĩnh. Máy phân tích tĩnh là công cụ tuyệt vời, nhưng chúng thiếu ý thức chung. Những số liệu này cần được xử lý bởi bộ não con người, tốt nhất là thuộc về một lập trình viên có kinh nghiệm. Chỉ sau đó bạn có thể biết nếu một phần mềm cụ thể là phức tạp không cần thiết.
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.