앵글 러 앱의 최대 순환 복잡도

Question

Cyclomatic Complexity에 쉽게 테스트하고 유지 관리 할 수있는 각도 앱 (각 컨트롤러, 서비스 등)이 있어야하는지 궁금합니다. 나는 Microsoft Documentation에서 Visual Studio가 25에서 경고 수준을 설정했지만, 언어/기술에 훨씬 더 의존적이라고 생각합니다.

Answer 1

Cyclomatic Complexity는 언어/기술에 의존하지 않습니다. 그것은 함수의 가능한 논리적 경로로부터 계산됩니다.

'최대'순환 복잡성은 없습니다. 높을수록 코드가 더 빨리 이해할 수 있습니다. 이 값이 높을수록 잘못 이해할 확률이 높아지며 수정을해야하는 경우 해당 함수에 버그가 있음을 알 수 있습니다.

코드를 유지 관리하거나 코드를 발전 시키려면이를 고려해야합니다. (유지 보수 비용은 너무 낮게 평가됩니다.)

이 질문은 Do you find cyclomatic complexity a useful measure? 몇 가지 중요한 답변이 있습니다.

개인적으로 나는 7의 규칙을 사용합니다. 과학적 연구에 따르면 인간의 뇌는 한 번에 7 가지만 개념을 파악할 수 있습니다. CC가> = 7 일 때, 함수의 줄 수가 7보다 크고, 클래스가 7보다 크고, 함수가> = 7 일 때 ... 내 디자인에 질문하기 시작한다. .

Answer 2

확실한 답변은 없습니다. CC 25는 어떤 언어로도 유지 보수 할 수 없을 가능성이 높습니다. 그렇습니다. 언어마다 다른 점이 있습니다. 어떤 언어에서는 함수를 사전에 넣을 수 있고 그 사전에서 함수를 선택하면 CC가 1 씩 증가하지만 람다를 가지고 있지 않은 다른 언어에서는 스위치 나 심지어 else-if 체인으로 갈 수 있습니다. 사례 당 하나의 참조가 추가되지만 모든 사례가 return;으로 끝나는 경우 유지 관리가 문제가되지 않습니다.

스테판이 말했듯이 7은 좋은 숫자이며 Java의 경우 7을 기본값으로하는 정적 코드 분석 도구가 있지만 함수를 2로 나누면 공식적으로 CC가 줄어들지 만 사람이 무슨 일이 일어나고 있는지에 따라 힘든 시간을 보내십시오.

각도 컨트롤러는 기능과 변수 만 정의하기 때문에 일반적으로 CC (< = 2)가 매우 낮습니다. 이 기능들은 CC의 의미에서 "복잡"해 보이지만 코드 흐름이 이제는 다른 기능 (예 : success() 또는 failure())에있을 것이므로 CC에 아무 것도 추가하지 않고도 promises입니다.