당신이 유지하는 기능의 가장 높은 사이클로틱 복잡성은 무엇입니까? 그리고 어떻게 리팩토링을 하시겠습니까?

Question

나는 내가 유지하는 레거시 시스템을 약간 탐색하고 있었다. ndepend 다른 날 (훌륭한 도구 확인). 내 연구 결과로 인해 화면 전체에 한 마리의 커피를 뿌렸습니다. 이 시스템의 상위 3 가지 기능은 사이클로 더 복잡성을 내림차순으로 순위가 매겨집니다.

1. someaspnetgridControl.CreateChildControls (CC of 171 !!!)
2. someformcontrol.addform (CC of 94)
3. SomesearchControl.splitcriteria (CC of 85)

171, 와우 !!! 그렇지 않아야합니다 20 미만 또는 뭔가? 그래서 이것은 나를 궁금해했다. 당신이 유지하거나 리팩토링 한 가장 복잡한 기능은 무엇입니까? 그리고 어떻게 그런 방법을 리팩토링 할 것인가?

메모: 내가 측정 한 CC는 IL이 아닌 코드를 초과합니다.

Answer 1

이것은 몇 년 전에 내가 일한 1970 년대 빈티지 코볼과 비교했을 때 어린이 물건입니다. 우리는 원본을 사용했습니다 McCabe 일부 코드의 CC를 그래픽으로 표시하는 도구. 기능적 경로를 보여주는 선이 너무 조밀하게 포장되고 스파게티와 같은 인쇄는 순수한 검은 색이었습니다. 나는 그림이 없지만 171보다 높아야했다.

해야 할 일

당 코드 완료 (초판):

점수가 :

• 0-5- 일상은 아마 괜찮을 것입니다
• 6-10- 루틴을 단순화하는 방법에 대해 생각하기 시작
• 10+ - 루틴의 일부를 두 번째 루틴으로 나누고 첫 번째 루틴에서 호출하십시오.

원래 루틴을 분해 할 때 단위 테스트를 작성하는 것이 좋습니다.

Answer 2

이것은 현재 제품에서 배송되는 C/C ++ 코드 용입니다.

내가 안정적으로 식별 할 수있는 가장 높은 CC 값 (즉, 도구가 관련없는 Main (...)에 대한 복잡성 값을 잘못 추가하고 있다고 생각하지 않습니다.

• 이미지 처리 기능 : 184
• 검증 된 데이터베이스 항목 로더 : 159

CC = 339의 테스트 서브 루틴도 있지만 배송 제품의 일부는 아닙니다. 그곳에서 구현 된 테스트 사례를 실제로 어떻게 확인할 수 있는지 궁금합니다 ...

그리고 네, 유죄를 보호하기 위해 기능 이름이 억제되었습니다. :)

변경 방법 :

이 문제를 해결하기위한 노력이 이미 있습니다. 문제는 대부분 두 가지 근본 원인으로 인해 발생합니다.

1. 스파게티 코드 (캡슐화 없음, 많은 카피 페이스트)
2. 실제 소프트웨어 구성/엔지니어링/목공 교육이없는 일부 과학자들이 제품 그룹에 제공하는 코드.

주요 방법은 스파게티의 응집력있는 조각을 식별하고 (실을 잡아 당기는 것)). 종종 함수 또는 도우미 클래스/객체로 추출 할 수있는 매핑 또는 변환이 있습니다. 손으로 만들어진 컨테이너 대신 STL을 사용하여 전환하면 반복자가 많은 코드를 잘라낼 수 있습니다. C- 스트링 대신 STD :: 문자열을 사용하면 많은 도움이됩니다.

Answer 3

나는 이것에 대한 또 다른 의견을 찾았다 이 블로그 항목 그것은 다양한 코드베이스와 비교할 때 좋은 의미가 있고 나에게 효과가있는 것 같습니다. 나는 그것이 고도로 의견이 많은 주제라는 것을 알고 있습니다.

• 1-10- 단순하고 많은 위험이 아닙니다
• 11-20- 복잡하고 낮은 위험
• 21-50- 너무 복잡하고 중간 위험,주의
• 50 이상 - 너무 복잡하고 테스트 할 수없고 위험이 높습니다.