코드 메트릭을 사용할 때 가장 잘 이해되지 않은 항목 중 하나는 순환 복잡성인 것 같습니다. 본질적으로, 순환 복잡성에서는 숫자가 높을수록 나쁘고 낮을수록 좋습니다. 주기적 복잡성을 사용하여 지정된 코드가 테스트, 유지 관리 또는 문제 해결에 얼마나 어려운지 파악하고 코드가 오류를 생성할 가능성을 나타낼 수 있습니다. 높은 수준에서 소스 코드에서 결정된 횟수를 계산하여 주기적 복잡성의 값을 결정합니다. 이 문서에서는 개념을 빠르게 이해하기 위한 간단한 주기적 복잡성 예제로 시작한 다음, 실제 사용량 및 제안된 제한에 대한 몇 가지 추가 정보를 살펴봅니다. 마지막으로, 이 주제에 대해 자세히 알아보는 데 사용할 수 있는 인용 섹션이 있습니다.
예시
주기적 복잡성은 NIST235"소스 코드 함수의 의사 결정 논리 양"을 측정하는 것으로 정의됩니다. 간단히 말해서, 코드에서 더 많은 결정을 내려야 할수록 더 복잡해집니다.
작동 중인 것을 살펴보겠습니다. 새 콘솔 애플리케이션을 만들고, 분석 메뉴로 이동하여 > 솔루션에 대한 코드 메트릭을 즉시 계산합니다.
주기적 복잡성은 2(가능한 가장 낮은 값)입니다. 비결정 코드를 추가하는 경우 복잡성은 변경되지 않습니다.
결정을 추가하면 주기적 복잡성 값이 1씩 올라갑니다.
if 문을 4가지 결정을 내릴 switch 문으로 변경하면 원래 2개에서 6개로 변경됩니다.
(가상의) 더 큰 코드 베이스를 살펴보겠습니다.
대부분의 항목은 Products_Related 클래스로 드릴다운할 때 값이 1이지만 그 중 몇 가지의 복잡성은 5입니다. 그 자체로는 이러한 차이가 큰 문제가 되지 않을 수 있습니다. 하지만 대부분의 다른 멤버들은 동일한 클래스에 하나씩 가지고 있으므로, 당신은 확실히 그 두 항목을 자세히 살펴보고 그 안에 무엇이 있는지 확인해야 합니다. 마우스 오른쪽 버튼을 클릭하고 상황 메뉴에서 소스 코드로 이동을 선택하여 항목을 자세히 살펴볼 수 있습니다.
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