코드 메트릭스의 매력은 무엇입니까? [닫은]

나는 최근에 많은 '코드 메트릭'관련 질문을 보았고 그 매력이 무엇인지 궁금해해야합니까? 다음은 최근 몇 가지 예입니다.

• 제공된 코드가 형편 없다고 확신하는 코드 메트릭
• 코드 줄 수가 유용한 메트릭 일 때
• 품질 테스트 작성

내 생각에는 어떤 메트릭도 코드 리뷰를 대체 할 수 없습니다.

• 일부 측정 항목은 검토가 필요한 장소를 나타낼 수 있습니다.
• 짧은 기간에 걸친 지표의 급격한 변화는 검토가 필요한 장소를 나타낼 수 있습니다.

그러나 나는 그 자체로 항상 '좋은'또는 '나쁜'코드를 나타내는 단일 메트릭을 생각할 수 없습니다. 측정으로 볼 수없는 것에 대한 예외와 이유가 항상 있습니다.

내가 간과 한 코드 메트릭에서 얻을 수있는 마법 같은 통찰력이 있습니까? 게으른 프로그래머 / 관리자는 코드를 읽지 않을 변명을 찾고 있습니까? 사람들이 거대한 레거시 코드 기반을 제시하고 시작할 곳을 찾고 있습니까? 무슨 일이야?

참고 : 특정 스레드에 대한 답변과 댓글 모두에 대해 이러한 질문 중 일부를 요청했지만 답변이 없었기 때문에 뭔가 빠졌을 수 있으므로 일반적으로 커뮤니티에 질문해야한다고 생각했습니다. 메트릭 배치 작업을 실행하고 실제로 다른 사람의 코드 (또는 내 자신의 코드)를 다시 읽을 필요가없는 것이 좋을 것입니다. 실용적이지 않다고 생각합니다!

편집 : 논의되는 모든 메트릭은 아니지만 대부분의 메트릭에 대해 잘 알고 있습니다. 단순히 또는 임의의 품질 표준으로 볼 수는 없습니다.

이 스레드의 답변은 다음과 같이 다소 이상합니다.

• "팀", "유일한 수혜자"처럼 말한 메트릭스;
• "메트릭"은 그 자체로 의미가있는 것처럼.

1 / Metrics는 한 모집단이 아니라 3 명을 위한 것입니다 .

• 개발자 : 코드의 정적 분석 (순환 복잡도, 주석 품질, 줄 수 등)과 관련된 즉각적인 정적 코드 메트릭 에 관심이 있습니다 .
• 프로젝트 리더 : 단위 테스트, 코드 커버리지, 지속적인 통합 테스트에서 발생 하는 일일 라이브 코드 메트릭에 관심이 있습니다.
• 비즈니스 후원자 (항상 잊혀지지 만 이해 관계자이며 개발 비용을 지불하는 사람) : 아키텍처 설계, 보안, 종속성 등과 관련된 주간 글로벌 코드 메트릭 에 관심이 있습니다 .

이러한 모든 메트릭은 물론 세 모집단 모두에서보고 분석 할 수 있지만 각 유형은 각 특정 그룹에서 더 잘 사용되도록 설계되었습니다.

2 / 메트릭은 그 자체로 코드 의 스냅 샷 을 나타내며 , 이는 의미가 없습니다.

"양호"또는 "나쁜"코드를 나타낼 수있는 것은 이러한 메트릭의 조합 및 다양한 분석 수준의 조합이지만 더 중요한 것은 해당 메트릭의 추세 가 중요하다는 것입니다.

이는 비즈니스 관리자 / 프로젝트 리더 / 개발자가 가능한 다양한 코드 수정 중에서 우선 순위 를 정하는 데 도움이되므로 실질적인 부가가치를 제공하는 메트릭 의 반복 입니다.

즉, "메트릭의 매력"에 대한 귀하의 질문은 다음과 같은 차이점을 나타낼 수 있습니다.

• "아름다운"코드 (항상 보는 사람-코더의 눈에 있음)
• "좋은"코드 (작동하고 작동 함을 증명할 수 있음)

예를 들어 순환 복잡도가 9 인 함수는 순환 복잡도가 42 인 긴 복잡한 함수와는 대조적으로 "아름다운"으로 정의 될 수 있습니다.

그러나 다음과 같은 경우 :

• 후자의 함수는 95 %의 코드 커버리지 와 결합 된 꾸준한 복잡성을 가지고 있습니다.
• 전자가 갖는 반면, 증가 복잡도 조합 의 ... 0 % 커버리지를

다음과 같이 주장 할 수 있습니다.

• 후자는 " 좋은 "코드를 나타냅니다 (작동하고 안정적이며 변경해야하는 경우 수정 후에도 작동하는지 확인할 수 있음).
• 전자는 " 나쁜 "코드입니다 (아직 수행해야하는 모든 작업을 처리하기 위해 몇 가지 케이스와 조건을 추가해야하며 회귀 테스트를 수행하는 쉬운 방법이 없습니다)

요약하면 다음과 같습니다.

그 자체로 항상 표시하는 단일 측정 항목 [...]

: 코드가 더 "아름답다"는 점을 제외하면 그 자체로 많은 의미는 아닙니다.

내가 간과 한 코드 메트릭에서 얻을 수있는 마법 같은 통찰력이 있습니까?

메트릭 의 조합 과 추세 만이 진정한 "마법의 통찰력"을 제공합니다.

나는 몇 달 전에 순환 복잡성을 측정하는 1 인 작업으로 수행 한 프로젝트가있었습니다. 그것은 이러한 종류의 측정 항목에 대한 저의 첫 노출이었습니다.

내가받은 첫 번째 보고서는 충격적이었습니다. 거의 모든 기능이 테스트를 통과하지 못했습니다. 심지어 매우 간단한 기능도 마찬가지였습니다. 논리적 하위 작업을 한 번만 호출하더라도 하위 루틴으로 이동하여 복잡한 문제를 해결했습니다.

나머지 절반의 루틴에 대해서는 프로그래머로서의 제 자부심이 시작되었고 동일한 방식으로 더 간단하고 읽기 쉽게 다시 작성하려고했습니다. 그게 효과가 있었고 저는 고객의 복잡성 임계 값을 최대한 낮출 수있었습니다.

결국 저는 거의 항상 더 나은 솔루션과 훨씬 더 깨끗한 코드를 찾을 수있었습니다. 성능에는이 문제가 없었습니다.

코드를 개선하기위한 이유 / 동기 부여로 메트릭을 사용한다면 메트릭스가 좋은 것이라고 생각합니다. 그래도 언제 멈추고 메트릭 위반 허가를 요청해야하는지 아는 것은 중요하지 않습니다.

지표는 그 자체로 끝나는 것이 아니라 가이드이자 도움이됩니다.

내가 사용한 최고의 측정 항목은 CRAP 점수 입니다.

기본적으로 가중 순환 복잡성을 자동화 된 테스트 범위와 비교하는 알고리즘입니다. 알고리즘은 다음과 같습니다. CRAP(m) = comp(m)^2 * (1 – cov(m)/100)^3 + comp(m) 여기서 comp (m)은 방법 m의 순환 복잡도이고 cov (m)은 자동화 된 테스트에서 제공하는 테스트 코드 범위입니다.

앞서 언급 한 기사의 저자는 다음과 같은 방식으로 분류되는 최대 30 점의 CRAP 점수를 제안합니다.

Method’s Cyclomatic Complexity        % of coverage required to be
                                      below CRAPpy threshold
------------------------------        --------------------------------
0 – 5                                   0%
10                                     42%
15                                     57%
20                                     71%
25                                     80%
30                                    100%
31+                                   No amount of testing will keep methods
                                      this complex out of CRAP territory.

빨리 보시다시피, 메트릭은 좋은 테스트 커버리지와 함께 복잡하지 않은 코드를 작성하는 데 보상을줍니다 (단위 테스트를 작성하고 커버리지를 측정하지 않는 경우 ... 글쎄요, 아마도 바람 속으로 침을 뱉는 것을 즐길 것입니다) 게다가). ;-)

대부분의 개발 팀에서 저는 CRAP 점수를 8 미만으로 얻기 위해 정말 열심히 노력했지만 충분한 테스트로 복잡성을 다루는 한 허용 가능한 추가 복잡성을 정당화 할 정당한 이유가 있다면. (복잡한 코드를 작성하는 것은 항상 테스트하기가 매우 어렵습니다 ...이 측정 항목의 숨겨진 이점입니다).

대부분의 사람들은 처음에 CRAP 점수를 통과하는 코드를 작성하는 것이 어렵다는 것을 알았습니다. 그러나 시간이 지남에 따라 더 나은 코드, 문제가 적은 코드, 디버그하기 훨씬 쉬운 코드를 작성했습니다. 모든 측정 항목 중에서 가장 우려되는 부분과 가장 큰 이점이있는 측정 항목입니다.

나에게 잘못된 코드를 식별하는 가장 중요한 단일 지표는 순환 적 복잡성입니다. 내 프로젝트의 거의 모든 방법이 CC 10 미만이며 CC가 30 이상인 레거시 방법에서 버그가 항상 발견됩니다. 높은 CC는 일반적으로 다음을 나타냅니다.

• 서둘러 작성된 코드 (즉, 복잡한 솔루션이 필요하기 때문이 아니라 우아한 솔루션을 찾을 시간이 없음)
• 테스트되지 않은 코드 (아무도 그런 짐승에 대한 테스트를 작성하지 않음)
• 여러 번 패치되고 수정 된 코드 (예 : ifs 및 todo 주석으로 가득 차 있음)
• 리팩토링의 주요 대상

좋은 코드 리뷰는 좋은 정적 분석 도구를 대체 할 수 없습니다. 물론 좋은 단위 테스트 세트를 대체 할 수 없습니다. 이제 단위 테스트는 승인 테스트 세트 없이는 좋지 않습니다.

코드 메트릭은 도구 상자에 넣을 수있는 또 다른 도구이며, 그 자체로는 솔루션이 아니며 적절하게 사용할 수있는 도구 일뿐입니다 (물론 다른 모든 도구도 포함됩니다!).

사람들은 코드를 이해하고 설명하는 기계적인 방법에 끌립니다. 사실이라면 효율성과 생산성에 대한 결과를 생각해보십시오!

"코드 우수성"에 대한 메트릭이 "좋은 산문"에 대한 메트릭만큼 합리적이라는 데 동의합니다. 그러나 이것이 메트릭스가 쓸모 없다는 것을 의미하지는 않으며 오용 될 수도 있습니다.

예를 들어, 일부 메트릭에 대한 극단적 인 값은 가능한 문제를 가리 킵니다 . 1000 줄 길이의 방법은 아마도 유지 관리 할 수 ​​없습니다. 단위 테스트 코드 커버리지가 0 인 코드에는 많은 테스트가있는 유사한 코드보다 더 많은 버그가 있을 수 있습니다. 타사 라이브러리가 아닌 단지 릴리스 전에 프로젝트에 추가 코드에서 큰 점프는 아마 특별한주의에 대한 원인.

지표를 제안 (적색 신호)으로 사용하면 유용 할 수 있습니다. 문제는 사람들이 SLOC에서 생산성을 측정하거나 테스트를 통해 라인의 백분율로 품질을 측정하기 시작할 때입니다.

나의 매우 주관적인 의견은 코드 메트릭스가 본질적으로 정량화 할 수없는 것을 정량화 할 수 있다는 것에 대한 거부 할 수없는 제도적 매력을 표현한다는 것입니다.

적어도 심리적으로는 의미가 있습니다. 평가하거나 이해할 수없는 것에 대해 어떻게 결정을 내릴 수 있습니까? 물론 궁극적으로 주제에 대해 잘 알고 있거나 (최소한 평가하려는 내용만큼 훌륭함) 지식이있는 사람에게 물어 보지 않는 한 품질을 평가할 수 없습니다. 한 걸음.

그런 의미에서 합리적인 비유는 SAT 점수로 대학 입학자를 평가하는 것일 수 있으며 불공평하고 모든 종류의 미묘함을 놓치지 만 정량화해야 할 경우 무언가를해야합니다.

그것이 좋은 척도라고 생각하지 않는다. 단지 나는 그것의 본질적인 저항 할 수없는 것을 볼 수있을 뿐이다. 그리고 당신이 지적했듯이, 아마도 몇 가지 합리적인 메트릭이있을 것입니다 (500 개 이상의 라인 메서드, 높은 복잡성, 아마도 나쁠 것임). 그래도 나는 이것을 구입 한 장소에 가본 적이 없습니다.

내가 믿는 코드 메트릭이 하나 있습니다.

저는 큰 시스템에서 일하고 있습니다. 하나의 새로운 요구 사항이 나오면 코딩을 시작했습니다. 작업을 마치고 버그가 해결되면 버전 관리 시스템에 확인합니다. 그 시스템은 diff를 수행하고 내가 만든 모든 변경 사항을 계산합니다.

그 숫자가 작을수록 좋습니다.

측정 항목과 자동화 된 테스트는 전체 코드 검토를 대체하기위한 것이 아닙니다.

속도를 높일뿐입니다. 자동 검사기를 사용하면 어떤 규칙을 따르지 않았는지, 지정된 패키지와 방법을 사용하고 있는지 등을 매우 쉽게 확인할 수 있습니다. 다른 사람의 시간을 사용하지 않고도 수정할 수있는 사항을 확인할 수 있습니다.

관리자는 또한 생산성에 대한 정확한 수치를 얻고 있다고 느끼고 (실제로는 그렇지는 않지만) 사람들을 더 잘 다룰 수 있어야한다고 느끼기 때문에 메트릭스를 좋아합니다.

측정은 다음과 같은 경우에만 유용합니다.

• 팀이 개발했습니다.
• 팀은 그들에게 동의했습니다
• 특정 영역을 식별하는 데 사용됩니다.

일반적으로 여기에 맞지 않는 측정 항목은 팀이이를 최적화하는 데 어려움을 겪습니다. 코드 라인을 측정하고 싶습니까? 이런, 그들이 얼마나 많이 쓸 수 있는지보세요! 당신은 코드 커버리지를 측정하고 싶어합니다.

메트릭은 추세를 식별하는 데 유용 할 수 있다고 생각하며 실제로 빌드가 중단 될 때 플로팅, 코드 변동 (프로젝트 전체에서 코드 줄 수 변경) 및 기타 사항과 같은 유용한 항목을 보았습니다. 그러나 팀이 그들과 함께 오지 않거나 그들이 동의하거나 이해하지 못한다면, 당신은 상처의 세계에있을 것입니다.

다음은 stan4j의 복잡성 메트릭입니다 .

이클립스 클래스 구조 분석 도구.

이 도구와 측정 항목이 마음에 듭니다. 나는 메트릭을 통계, 지표, 경고 메시지로 취급합니다. 때로는 일부 메서드 또는 일부 클래스로 인해 복잡한 논리가있어 복잡하게 만들 수 있습니다. 수행해야 할 작업은이를 주시하고 검토하여 리팩토링 할 필요가 있는지 검토하거나 신중하게 검토하는 것입니다. 오류가 발생하기 쉽습니다. 또한 복잡한 것부터 간단한 것까지 배우는 것을 좋아하기 때문에 소스 코드를 배우기위한 분석 도구로 사용합니다. 실제로는 Robert C. Martin Metrics, Chidamber & Kemerer Metrics, Count Metrics와 같은 다른 메트릭을 포함하지만 이것이 가장 좋습니다

복잡성 메트릭

순환 복잡성 메트릭

순환 복잡성 (CC) 방법 의 순환 복잡성은 방법의 제어 흐름 그래프에서 1 씩 증가하는 결정 지점의 수입니다. 결정 지점은 제어 흐름이 단순한 선형이 아닌 if / for / while 문, case / catch 절 및 유사한 소스 코드 요소에서 발생합니다. 단일 (소스 코드) 문에 의해 도입 된 (바이트 코드) 결정 지점의 수는 예를 들어 부울 표현식의 복잡성에 따라 달라질 수 있습니다. 메서드의 순환 복잡성 값이 높을수록 메서드 제어 흐름 그래프의 모든 분기를 테스트하는 데 더 많은 테스트 케이스가 필요합니다.

평균 순환 복잡도 응용 프로그램, 라이브러리, 패키지 트리 또는 패키지의 모든 방법에 대한 순환 복잡도 메트릭의 평균 값입니다.

Fat Metrics 아티팩트의 Fat 메트릭은 아티팩트의 적절한 종속성 그래프에있는 간선의 수입니다. 종속성 그래프 유형은 메트릭 변형 및 선택한 아티팩트에 따라 다릅니다.

Fat 응용 프로그램, 라이브러리 또는 패키지 트리의 Fat 메트릭은 하위 트리 종속성 그래프의 가장자리 수입니다. 이 그래프에는 패키지 트리 계층 구조에있는 모든 아티팩트의 하위 항목이 포함되어 있으므로 리프 패키지도 포함됩니다. (컴포지션 뷰에서 적절한 그래프를 보려면 구조 탐색기의 플랫 패키지 토글을 비활성화해야합니다. 선택한 아티팩트가 라이브러리 인 경우 라이브러리 표시 토글을 활성화해야하며 그렇지 않으면 비활성화해야합니다.)

패키지의 Fat 메트릭은 단위 종속성 그래프의 에지 수입니다. 이 그래프에는 패키지의 모든 최상위 클래스가 포함됩니다.

클래스의 Fat 메트릭은 멤버 그래프의 간선 수입니다. 이 그래프에는 클래스의 모든 필드, 메서드 및 멤버 클래스가 포함됩니다. (이 그래프와 Fat 값은 Class가 아닌 Level of Detail Member로 코드 분석을 수행 한 경우에만 사용할 수 있습니다.)

Fat for Library Dependencies (Fat-Libraries) 응용 프로그램의 Fat for Library Dependencies 메트릭은 라이브러리 종속성 그래프의 에지 수입니다. 이 그래프에는 애플리케이션의 모든 라이브러리가 포함됩니다. (컴포지션보기에서 적절한 그래프를 보려면 구조 탐색기의 라이브러리 표시 토글을 활성화해야합니다.)

플랫 패키지 종속성에 대한 지방 (Fat-패키지) 응용 프로그램의 플랫 패키지 종속성에 대한 지방 메트릭은 플랫 패키지 종속성 그래프의 에지 수입니다. 이 그래프에는 애플리케이션의 모든 패키지가 포함됩니다. (컴포지션 뷰에서 적절한 그래프를 보려면 구조 탐색기의 플랫 패키지 토글을 활성화하고 라이브러리 표시 토글을 비활성화해야합니다.)

라이브러리의 플랫 패키지 종속성에 대한 지방 메트릭은 플랫 패키지 종속성 그래프의 에지 수입니다. 이 그래프에는 라이브러리의 모든 패키지가 포함됩니다. (컴포지션 뷰에서 적절한 그래프를 보려면 구조 탐색기의 플랫 패키지 및 라이브러리 표시 토글을 활성화해야합니다.)

최상위 클래스 종속성에 대한 지방 (지방-단위) 응용 프로그램 또는 라이브러리의 최상위 클래스 종속성에 대한 지방 메트릭은 해당 단위 종속성 그래프의 가장자리 수입니다. 이 그래프에는 애플리케이션 또는 라이브러리의 모든 최상위 클래스가 포함됩니다. (합리적인 응용 프로그램의 경우 너무 커서 시각화 할 수 없으므로 구성보기에 표시 할 수 없습니다. 단위 종속성 그래프는 패키지에 대해서만 표시 될 수 있습니다.)

메트릭은 프로젝트의 개선 또는 저하를 결정하는 데 유용 할 수 있으며 스타일 및 규칙 위반을 확실히 찾을 수 있지만 피어 코드 검토를 수행하는 대신 사용할 수있는 방법은 없습니다. 그들 없이는 코드의 품질을 알 수 없습니다.

오 ... 그리고 이것은 당신의 코드 리뷰 참가자 중 적어도 한 명이 단서를 가지고 있다고 가정합니다.

코드 메트릭스가 코드 리뷰를 대체해서는 안된다는 데 동의하지만 코드 리뷰를 보완해야한다고 생각합니다. "측정 할 수없는 것을 개선 할 수 없다"는 옛말로 돌아가는 것 같습니다. 코드 메트릭은 추가 조사가 필요할 수있는 수량화 가능한 "코드 냄새"또는 패턴을 개발 팀에 제공 할 수 있습니다. 대부분의 정적 분석 도구에서 캡처되는 메트릭은 일반적으로 우리 분야의 짧은 역사에서 연구 과정에서 중요한 의미를 갖는 것으로 확인 된 메트릭입니다.

메트릭은 코드 검토를 대체하지는 않지만 훨씬 저렴합니다. 그것들은 무엇보다 지표입니다.

대답의 한 부분은 일부 코드 메트릭이 다음 질문에 대한 답을 매우 빠르게 초기에 찌르는 것을 제공 할 수 있다는 것입니다.이 코드는 어떤가요?

'코드 라인'조차도보고있는 코드베이스의 크기에 대한 아이디어를 제공 할 수 있습니다.

다른 답변에서 언급했듯이 메트릭 추세는 가장 많은 정보를 제공합니다.

그 자체의 지표는 특별히 흥미롭지 않습니다. 중요한 것은 당신이 그들과하는 일입니다.

예를 들어 코드 줄당 주석 수를 측정하는 경우 좋은 가치는 무엇이라고 생각하십니까? 누가 알아? 또는 더 중요한 것은 모든 사람이 자신의 의견을 가지고 있다는 것입니다.

이제 코드 줄당 주석 수를 버그를 해결하는 데 걸린 시간 또는 코딩으로 인해 발견 된 버그 수와 연관시킬 수있을만큼 충분한 정보를 수집하면 경험적으로 유용한 수를 찾기 시작할 수 있습니다. .

소프트웨어에서 메트릭을 사용하는 것과 다른 프로세스에서 다른 성능 측정을 사용하는 것에는 차이가 없습니다. 먼저 측정 한 다음 분석 한 다음 프로세스를 개선합니다. 측정 만한다면 시간을 낭비하는 것입니다.

편집 : Steven A. Lowe의 의견에 대한 응답으로 – 그것은 절대적으로 정확합니다. 모든 데이터 분석에서 인과 관계와 단순한 상관 관계를 구별하는 데주의해야합니다. 그리고 적합성을 기준으로 메트릭을 선택하는 것이 중요합니다. 커피 소비량을 측정하고 코드 품질을 평가하는 데는 아무런 의미가 없습니다 (일부는 시도해 보았지만 ;-))

그러나 관계 (인과 적 여부)를 찾기 전에 데이터가 있어야합니다.

수집 할 데이터의 선택은 확인하거나 개선하려는 프로세스를 기반으로합니다. 예를 들어, 코드 검토 절차의 성공을 분석하려는 경우 ( "성공"에 대한 자체 정의를 사용하여 버그 감소 또는 코딩 버그 감소 또는 처리 시간 단축 등) 측정하는 메트릭을 선택합니다. 검토 된 코드의 총 버그 비율 및 버그 비율

따라서 데이터를 수집하기 전에 데이터로 무엇을하고 싶은지 알아야합니다. 메트릭이 수단이라면 끝은 무엇입니까?

나는 메트릭스의 작은 변화가 의미가 없다고 생각합니다. 복잡도가 20 인 함수가 복잡도가 30 인 함수보다 반드시 깨끗한 것은 아닙니다. 그러나 큰 차이를 찾기 위해 메트릭을 실행하는 것은 가치가 있습니다.

한 번은 수십 개의 프로젝트를 조사 할 때 프로젝트 중 하나는 최대 복잡성 값이 약 6,000이고 다른 모든 프로젝트의 값은 약 100 이하였습니다. 그것은 야구 방망이처럼 머리 위로 나를 때렸다. 분명히 특이하고 아마도 나쁜 일이 그 프로젝트에서 진행되고있었습니다.

우리는 프로그래머입니다. 우리는 숫자를 좋아합니다.

또한 "코드 메트릭 라인이 무관"하기 때문에 코드베이스의 크기를 설명하지 않고 무엇을 하시겠습니까?

어리석은 예를 들어 보면 150 줄의 코드베이스와 1 억 5 천만 줄의 코드베이스 사이에는 확실히 차이가 있습니다. 그리고 그것은 얻기 어려운 숫자가 아닙니다.