답변:
Cyclomatic의 복잡성은 나에게 정확히 무엇을 말하고 있습니까?
순환 복잡도는 코드 라인의 척도가 아니라 모듈을 통한 독립적 인 경로의 수입니다. 순환 복잡도 17,754는 응용 프로그램에 17,754 개의 고유 한 경로가 있음을 의미합니다. 여기에는 일반적으로 응용 프로그램을 이해하고 테스트하기가 얼마나 어려운지에 대한 몇 가지 의미가 있습니다. 예를 들어, 순환 복잡성은 잘 작성된 테스트를 가정하여 100 % 분기 적용 범위를 달성하는 데 필요한 테스트 사례 수입니다.
순환 적 복잡성에 관한 Wikipedia 기사 가 좋은 출발점이 될 수있다 . 여기에는 몇 개의 유사 코드 스 니핏과 사이클로 메틱 복잡성이 무엇인지 보여주는 일부 그래프가 있습니다. 더 많은 것을 알고 싶다면 McCabe의 논문에서 그가 순환 복잡성을 정의한 곳을 읽을 수도 있습니다 .
내 응용 프로그램은 17,754 줄의 Cyclomatic 복잡성을 가지고 있습니다. 응용 프로그램 자체는 37,672 줄의 코드입니다. 코드 라인에 따라 복잡성이 높다고 말하는 것이 타당합니까?
전혀. 코드 라인이 적고 루프 내에 중첩 된 많은 수의 조건이있는 애플리케이션은 순환 복잡성이 매우 클 수 있습니다. 반면에 조건이 적은 애플리케이션은 순환 복잡성이 낮을 수 있습니다. 그것은 그것을 지나치게 단순화하는 것이지만, 나는 그것이 아이디어를 뛰어 넘을 것이라고 생각합니다.
응용 프로그램의 기능에 대해 더 많이 알지 못하면 순환 복잡성이 더 높은 것이 일반적 일 수 있습니다. 그러나 응용 프로그램 수준 대신 클래스 또는 메서드 수준에서 순환 복잡성을 측정하는 것이 좋습니다. 이것은 개념적으로 좀 더 다루기 쉽고, 큰 응용 프로그램을 통한 경로보다 방법을 통해 경로를 시각화하거나 개념화하는 것이 더 쉽다고 생각합니다.
순환 복잡도는 코드를 리팩터링해야하는지 여부를 결정하는 방법입니다. 코드가 분석되고 복잡도가 결정됩니다. 복잡도는 분기 (if 문 등)에 의해 결정됩니다. 복잡도는 루프 등의 중첩 및 사용 된 알고리즘에 따라 다른 요소를 고려할 수도 있습니다.
숫자는 분석법 수준에서 유용합니다. 높은 수준에서는 숫자 일뿐입니다.
17,754 개의 숫자는 프로젝트 수준의 복잡성 (총 코드)을 나타내며 그다지 의미가 없습니다.
클래스 및 방법 수준의 복잡성으로 드릴 다운하면 더 작은 방법으로 리팩토링되거나 복잡성을 제거하기 위해 재 설계해야하는 코드 영역이 결정됩니다.
CASE한 가지 방법으로 50 개의 사례가 있는 진술을 고려하십시오 . 각 주마다 비즈니스 로직이 다를 수 있습니다. 순환 순환 복잡성이 50이됩니다. 50 개의 의사 결정 지점이 있습니다. 분기 논리를 제거하기 위해 팩토리 패턴을 사용하여 CASE 문을 다시 디자인해야 할 수도 있습니다. 때로는 리팩토링 (메소드를 더 작은 부분으로 분해) 할 수 있으며 경우에 따라 재 설계만으로 복잡성을 줄일 수 있습니다.
일반적으로 메소드 레벨 복잡성에 대해 :
또한 복잡성이 높을수록 코드를 단위 테스트하기가 더 어려워집니다.
단일 메서드에서 가장 복잡했던 것은 560입니다. 한 메서드에서 약 2000 줄의 if 문이있었습니다. 기본적으로 유지 관리 할 수없고 테스트 할 수 없으며 잠재적 인 버그로 가득합니다. 해당 분기 논리에 필요한 모든 단위 테스트 사례를 상상해보십시오! 안좋다.
모든 방법을 20 미만으로 유지하고 덜 복잡하게 만들기 위해 모든 방법을 리팩토링하는 데 비용이 드는 것을 인식하십시오.
응용 프로그램에서 고유 한 경로 수입니다. CC 에서이 IBM 기사를 확인하십시오 .
그것은 높은 것처럼 보이지만 귀하의 경우 모든 클래스 및 메소드의 모든 메소드의 CC를 추가하는 것입니다. 코드가 어떻게 구성되어 있는지 모르기 때문에 예제가 많이 확장되었지만 37672 줄의 코드가있는 괴물 방법이나 약 10 줄의 코드가있는 3767 방법이있을 수도 있습니다. 의미하는 것은 응용 프로그램 수준 에서이 표시기는 그다지 의미가 없지만 방법 수준에서는 오류가 덜 발생하도록 코드를 더 작은 방법으로 최적화 / 다시 작성하는 데 도움이 될 수 있습니다.
개인적으로 많이 읽은 것은 CC가 10보다 높은 방법은 결함 위험이 높다는 것입니다.
Sonar 를 사용 하여 응용 프로그램의 코드 품질을 테스트하고 기본적으로 +10 CC가있는 메소드가 있으면 경고가 발생한다고 생각합니다. 여전히 그것은 아무 의미가 없습니다. 구체적인 예 : Eclipse를 사용 equals하여 Bean의 특성을 기반으로 메소드 를 생성하는 경우 CC는 매우 빠르게 지붕 위로 올라갑니다.
equals방법 과 같이 CC가 높은 이유가있을 수있는 방법을 무시할 수 있습니다 .
어떤 도구를 사용 하느냐에 따라 다릅니다. 오픈 소스 도구 중 일부는 모듈로 클래스를 사용하거나 모듈로 다른 레벨의 구조를 갖습니다. 따라서 프로젝트가 커질수록 Cyclomatic Complexity는 높아집니다. 그러나 개인적인 이해를 위해서는 기능 기반에 있어야합니다. 프로젝트의 규모가 커질수록 그 기능을 수행합니다.
Lizard라는 도구를 사용하는 것이 좋으며 github에서 리소스 코드를 찾고 zip 파일을 다운로드 할 수 있습니다. 코드에 기밀 정보가 많지 않은 경우 온라인 버전도 있습니다.
주의해야 할 의미있는 CCN은 다른 기능 기반에 있습니다. 또한 각 기능의 CCN unber 15를 이상적인 범위로 유지하십시오.