코드 메트릭 - 순환 복잡성

코드 메트릭을 사용할 때 가장 이해도가 떨어지는 항목 중 하나가 순환 복잡성인 것 같습니다. 기본적으로 순환 복잡성은 숫자가 높을수록 불량하고 숫자가 낮을수록 양호합니다. 순환 복잡성을 사용하여 특정 코드를 테스트, 유지 관리 또는 문제 해결하기가 얼마나 어려운지 파악하고 코드가 오류를 생성할 가능성을 나타낼 수 있습니다. 개략적으로, 순환 복잡성 값은 소스 코드에서 포함된 의사 결정 횟수를 계산하여 결정합니다. 이 문서에서는 개념을 빠르게 이해하기 위한 간단한 순환 복잡성 예제로 시작한 다음, 실제 사용 및 제안된 제한에 대한 몇 가지 추가 정보를 살펴봅니다. 마지막으로, 이 주제에 대해 자세히 알아보는 데 사용할 수 있는 인용문 섹션이 있습니다.

예시

순환 복잡성은 "소스 코드 함수의 의사 결정 논리 양"을 측정하는 것으로 정의됩니다(NIST235). 간단히 말해, 코드에서 결정해야 하는 것이 많을수록 더 복잡한 것입니다.

작동을 확인합니다. >새 콘솔 애플리케이션을 만들고 분석 > 솔루션에 대해 코드 메트릭 계산으로 이동하여 코드 메트릭을 즉시 계산합니다.

순환 복잡성은 2(가능한 가장 낮은 값)입니다. 비 의사 결정 코드를 추가하는 경우 복잡성이 변경되지 않습니다.

의사 결정을 추가하면 순환 복잡성 값이 1씩 상승합니다.

if 문을 4개의 의사 결정을 수행할 switch 문으로 변경하면 값이 원래 2에서 6으로 상승합니다.

(가상의) 더 큰 코드 베이스를 살펴보겠습니다.

Products_Related 클래스로 드릴다운할 때 대부분의 항목은 값이 1이지만 두 항목은 복잡성이 5입니다. 그 자체로는 큰 문제가 아닐 수 있지만, 동일한 클래스에 있는 다른 멤버는 대부분 1이라는 점을 감안하면 두 항목에 무엇이 있는지 더 자세히 살펴보아야 합니다. 이렇게 하려면 항목을 마우스 오른쪽 단추로 클릭하고 바로 가기 메뉴에서 소스 코드로 이동을 선택합니다. Product.set(Product)에 대해 좀더 자세히 살펴보겠습니다.

모든 if 문을 보면 순환 복잡성이 5인 이유를 알 수 있습니다. 이 시점에서 이 값을 허용되는 복잡성 수준으로 결정하거나 리팩터링하여 복잡성을 줄일 수 있습니다.

매직 넘버

이 업계의 많은 메트릭과 마찬가지로 모든 조직에 맞는 정확한 순환 복잡성 제한은 없습니다. 그러나 NIST235는 10이라는 제한이 좋은 시작점임을 나타냅니다.

"제한으로 사용할 정확한 수는 여전히 논란의 여지가 있습니다. McCabe에서 제안한 원래 제한인 10은 상당한 지지 증거가 있지만 15까지의 제한도 성공적으로 사용되었습니다. 10 이상의 제한은 숙련된 직원, 공식 디자인, 최신 프로그래밍 언어, 구조화 프로그래밍, 코드 연습, 포괄적인 테스트 계획 등 일반적인 프로젝트에 비해 운영상 이점이 다수 있는 프로젝트에 적용되어야 합니다. 즉, 조직은 10보다 큰 복잡성 제한을 선택할 수 있지만, 조직이 어떤 작업을 수행하는지 잘 알고 있고 더 복잡한 모듈에 필요한 테스트 노력을 추가로 경주하려는 경우에만 선택할 수 있습니다." NIST235

순환 복잡성 및 줄 번호

코드 줄 수 자체를 살펴보는 것만으로도 코드 품질을 대략적으로나마 예측할 수 있습니다. 함수에 코드 줄이 많을수록 오류가 있을 가능성이 높다는 개념은 기본적으로 사실입니다. 그러나 순환 복잡성을 코드 줄 수와 결합하면 오류가 발생할 가능성을 훨씬 명확하게 파악할 수 있습니다.

NASA의 SATC(Software Assurance Technology Center)에서 설명한 대로 다음을 수행합니다.

"SATC에서는 가장 효과적인 평가가 크기와 (순환) 복잡성의 조합임을 발견했습니다. 복잡성도 높고 크기도 큰 모듈은 안정성이 가장 낮은 경향이 있습니다. 크기가 작고 복잡성이 높은 모듈 역시 변경 또는 수정하기 어려운 매우 복잡한 코드인 경향이 있으므로 안정성 위험이 있습니다." SATC

코드 분석

코드 분석에는 유지 관리 규칙 범주가 포함됩니다. 자세한 내용은 유지 관리 규칙을 참조하세요. 레거시 코드 분석을 사용하는 경우 확장 디자인 지침 규칙 집합에는 유지 관리 영역이 포함됩니다.

유지 관리 영역 내에는 복잡성에 대한 규칙이 있습니다.

이 규칙은 순환 복잡성이 25에 도달하면 경고를 생성하여 과도한 복잡성을 방지하는 데 도움이 될 수 있습니다. 이 규칙에 대한 자세한 내용은 CA1502를 참조하세요.

총정리

결론적으로 복잡성 점수가 높으면 유지 관리 및 문제 해결 시간이 늘어나고 오류가 발생할 확률이 높아집니다. 복잡성이 높은 함수를 자세히 살펴보고 덜 복잡하게 리팩터링해야 하는지 여부를 결정하세요.

인용문

MCCABE5

McCabe, T. and A. Watson (1994), Software Complexity(CrossTalk: The Journal of Defense Software Engineering).

NIST235

&Watson, A. H., & McCabe, T. J. Structured Testing: A Testing Methodology Using the Cyclomatic Complexity Metric (NIST Special Publication 500-235). 2011년 5월 14일 McCabe Software 웹 사이트에서 검색: http://www.mccabe.com/pdf/mccabe-nist235r.pdf

SATC

Rosenberg, L., Hammer, T., Shaw, J. (1998). Software Metrics and Reliability(Proceedings of IEEE International Symposium on Software Reliability Engineering). 2011년 5월 14일 Penn State University 웹 사이트에서 검색: https://citeseerx.ist.psu.edu/pdf/31e3f5732a7af3aecd364b6cc2a85d9495b5c159