코드 메트릭 - 순환 복잡성

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

본보기

주기적 복잡성은 NIST235"소스 코드 함수의 의사 결정 논리 양"을 측정하는 것으로 정의됩니다. 간단히 말해서, 코드에서 더 많은 결정을 내려야 할수록 더 복잡해집니다.

작동 중인 것을 살펴보겠습니다. 새 콘솔 애플리케이션을 만들고, 분석 메뉴로 이동하여 > 솔루션에 대한 코드 메트릭 계산을 즉시 수행합니다.

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

결정을 추가하면 주기적 복잡성 값이 1씩 올라갑니다.

if 문을 4가지 결정을 내릴 switch 문으로 변경하면 원래 2개에서 6개로 변경됩니다.

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

대부분의 항목은 Products_Related 클래스를 자세히 살펴보면 값이 1이지만, 그 중 일부는 복잡성이 5입니다. 그 자체로 이러한 차이는 큰 문제가 되지 않을 수 있지만, 대부분의 다른 멤버가 같은 클래스에 하나를 가지고 있으므로, 당신은 그 두 항목을 자세히 살펴보고 그 안에 무엇이 있는지 확인해야 합니다. 항목을 마우스 오른쪽 단추로 클릭하고 상황에 맞는 메뉴에서 Go To Source Code를 선택하여 자세히 살펴볼 수 있습니다. 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. 및 A. Watson (1994), 소프트웨어 복잡성 (CrossTalk: The Journal of Defense Software Engineering).

NIST235

왓슨, A. H., & 맥케이브, T. J. (1996). 구조적 테스트: 순환 복잡성 메트릭을 사용하는 테스트 방법론(NIST 특수 발행물 500-235). 2011년 5월 14일 McCabe Software 웹 사이트에서 검색됨: http://www.mccabe.com/pdf/mccabe-nist235r.pdf

SATC (섹스 앤 더 시티)

로젠버그, L., 해머, T., 쇼, 제이 (1998). 소프트웨어 측정 및 신뢰성(IEEE 국제 소프트웨어 신뢰성 공학 심포지엄 논문집). 2011년 5월 14일, 펜 주립대학 웹 사이트에서 검색: https://citeseerx.ist.psu.edu/pdf/31e3f5732a7af3aecd364b6cc2a85d9495b5c159