순환 복잡성 범위

폐쇄되었습니다 . 이 질문은 의견 기반 입니다. 현재 답변을받지 않습니다.

이 질문을 개선하고 싶습니까? 이 게시물 을 편집 하여 사실과 인용으로 답변 할 수 있도록 질문을 업데이트하십시오 .

휴일 오년 전에 .

순환 복잡성의 범주는 무엇입니까? 예를 들면 다음과 같습니다.

1-5 : 유지 보수 용이
6-10 : 어려움
11-15 : 매우 어려움
20+ : 접근 불가

몇 년 동안 저는 10이 한계라고 가정했습니다. 그리고 그 이상은 나쁘다. 솔루션을 분석 중이며 코드 품질을 결정하려고합니다. 확실히 순환 복잡성 만이 유일한 측정은 아니지만 도움이 될 수 있습니다. 순환 복잡성이 200+ 인 방법이 있습니다. 나는 그것이 끔찍하다는 것을 알고 있지만 위의 예에서와 같이 더 낮은 범위에 대해 알고 싶습니다.

나는 이것을 발견 했다 :

Carnegie Mellon의 앞에서 언급 한 기준 값은 순환 복잡도 값에 대한 네 가지 거친 범위를 정의합니다.

1에서 10 사이의 방법은 간단하고 이해하기 쉬운 것으로 간주됩니다

10에서 20 사이의 값은 더 이해하기 쉬운 코드를 나타내며 여전히 이해할 수 있습니다. 그러나 코드가 취할 수있는 가능한 많은 분기로 인해 테스트가 더 어려워집니다.

20 이상의 값은 잠재적 인 실행 경로가 매우 많은 코드의 전형적인 것이며 큰 어려움과 노력으로 완전히 파악하고 테스트 할 수 있습니다.

예를 들어> 50보다 훨씬 더 높은 방법은 확실히 유지가 불가능합니다

솔루션에 대한 코드 메트릭을 실행할 때 결과는 25 미만인 경우 녹색으로 표시됩니다. 이에 동의하지 않지만 다른 입력을 받기를 희망했습니다.

순환 복잡성에 대해 일반적으로 허용되는 범위 목록이 있습니까?

design programming-practices metrics

— 밥 혼
소스

소프트웨어 엔지니어링의 리더로 인정되는 조직인 Software Engineering Institute에서 데이터를 찾았습니다. 귀하의 질문이 무엇인지 이해하지 못합니다-순환 복잡성에 대한 범위 목록을 찾았습니다. 다른 무엇을 찾고 있습니까?

— Thomas Owens

나는 다양한 범위를 보았다; 그것은 단지 하나의 예일뿐입니다. 그리고 MS는 25 세 미만의 모든 것에 대해 "녹색"을 표시합니다. 허용 범위 목록 이 하나 있는지 궁금 합니다. 아마도 나는 그때 그것을 찾았습니다.

— Bob Horn

@ThomasOwens에 동의하지만이 질문을하게되어 기쁩니다. 나는 그것을 질문과 답변으로 공증했다.

— Evorlor

Steve McConnell의 Code Complete 제 2 판에서는 일반적으로 0에서 5까지의 순환 복잡성이 좋지만, 복잡성이 6-10 범위에 도달하기 시작하는지 알고 있어야합니다. 그는 또한 10의 복잡성을 초과하는 것은 코드 리팩토링을 고려해야한다고 설명합니다.

— GibboK

답변:

나는 그것이 프로그래밍 직원의 능력에 달려 있고 관리자로서의 감수성에도 크게 영향을 미치지 않는다고 생각합니다.

일부 프로그래머는 TDD를 강력하게 옹호하며 먼저 단위 테스트를 작성하지 않으면 코드를 작성하지 않습니다. 다른 프로그래머는 단일 단위 테스트를 작성하지 않고도 완벽하게 버그가없는 프로그램을 완벽하게 만들 수 있습니다. 각 그룹이 견딜 수있는 순환 복잡성의 수준은 거의 확실하게 변할 것입니다.

주관적인 지표입니다. Code Metrics 솔루션의 설정을 평가하고 편안한 느낌을주는 적절한 지점으로 조정하여 합리적인 결과를 얻습니다.

— 로버트 하비
소스

더 나아가서, 그것은 복잡성의 원인이 무엇인지에 달려 있습니다. 상태 머신 또는 이와 유사한 것의 일부로 다른 함수를 호출하는 큰 스위치 문은 이해하기가 쉽지 않지만 매우 복잡 할 수 있습니다.

— whatsisname

큰 스위치 문은 일반적으로 다형성과 같은 OOP 원칙이 부족하다는 표시가 아닙니까? OOP 또는 디자인 패턴을 사용하여 상태 머신을 우아한 방식으로 구현할 수 있습니다. 아니?

— 밥 호른

'우아함'이 유용한 일부 문제의 경우 다른 사람들에게는 '혼란'을 더 혼란스럽게 만듭니다. 은 총알이 없습니다.

— whatsisname

-1 "다른 프로그래머는 단일 단위 테스트를 작성하지 않고도 완벽하게 버그가없는 프로그램을 완벽하게 만들 수 있습니다." 테스트하지 않은 경우 버그가 없는지 알 수 없습니다.

— Sebastien

@Sebastien : 단위 테스트가 없다고해서 테스트되지 않았다는 의미는 아닙니다. 그렇습니다. 충분히 능숙하다면 테스트 나 기본적인 연기 테스트없이 버그가없는 코드를 작성하는 것이 절대적으로 가능합니다. 틀림없이, 그 사람들은 드문 품종입니다.

— Robert Harvey

사전 정의 된 카테고리가 없으며 몇 가지 이유로 분류가 불가능합니다.

일부 리팩토링 기법은 (하지에서 한 지점에서 다른 지점으로 복잡성을 이동 하여 코드 프레임 워크 또는 잘 테스트 외부 라이브러리에,하지만 한 위치에서 코드베이스의 다른). 그것은 순환적인 복잡성을 줄이는 데 도움이되고 사장님 (또는 지속적으로 증가하는 그래픽으로 프리젠 테이션을 좋아하는 사람)이 훌륭한 무언가를 만드는 데 시간을 보냈지 만 코드는 이전처럼 나쁘게 유지되도록 도와줍니다.
반대로, 때로는 일부 디자인 및 프로그래밍 패턴을 적용하여 프로젝트를 리팩터링하면 순환 복잡성이 악화 될 수 있지만 리팩터링 된 코드는 명확해질 것으로 예상됩니다. 따라서 코드를 단순화하지만 순환 복잡성은 이것을 고려하지 않습니다.
다른 비 리팩토링 기술은 순환 복잡성에 전혀 영향을 미치지 않으면 서 개발자의 코드 복잡성을 크게 줄입니다. 예 : 관련 의견 또는 문서 추가 구문 설탕을 사용하여 코드를 "현대화"합니다.
순환 복잡성에 관련이없는 경우가 있습니다. 나는 그의 의견에서 whatsisname에 의해 주어진 예를 좋아한다 . 일부 큰 switch문장은 매우 명확 할 수 있으며 더 OOPy 방식으로 다시 작성하는 것은별로 유용하지 않을 것입니다 (초보자가 코드를 이해하는 것을 복잡하게 만듭니다). 동시에 이러한 진술은 복잡하고 순환적인 재앙입니다.
Robert Harvey는 이미 위에서 말했듯 이 팀 자체에 달려 있습니다.

실제로, 나는 순환 적으로 복잡하지만 좋은 끔찍한 소스 코드를 보았습니다. 동시에 순환 사이클 복잡성이 높은 코드를 보았지만 이해하는 데 많은 어려움이 없었습니다.

그것은 단지 주어진 코드 조각이 얼마나 좋고 나쁘거나 유지하기가 쉬운지를 완벽하게 나타내는 도구가 없으며 도구가 될 수 없다는 것 입니다. 주어진 그림이 걸작이고 다른 그림은 예술적 가치가 없기 때문에 버려야한다는 응용 프로그램을 프로그래밍 할 수 없습니다.

LOC 또는 파일 당 주석 수와 같이 의도적으로 설계된 메트릭이 있으며 버그 수 또는 순환 복잡성과 같은 몇 가지 원시 힌트를 제공 할 수있는 메트릭이 있습니다. 모든 경우에 이것은 힌트 일 뿐이므로주의해서 사용해야합니다.

— 아르 세니 무르 첸코
소스

+1 나는 모든 말에 동의합니다. 순환 복잡성 또는 LOC는 정적 코드 분석을 통해 제공되는 메트릭입니다. 정적 분석기는 훌륭한 도구이지만 상식이 없습니다. 이러한 측정 항목은 인간의 두뇌, 바람직하게는 숙련 된 프로그래머에 의해 처리되어야합니다. 그래야만 특정 소프트웨어가 불필요하게 복잡한 지 알 수 있습니다.