나는 최근에 많은 ‘코드 메트릭’관련 질문을 보았고 그 매력이 무엇인지 궁금해해야합니까? 다음은 최근 몇 가지 예입니다.
내 생각에는 어떤 메트릭도 코드 리뷰를 대체 할 수 없습니다.
- 일부 측정 항목은 검토가 필요한 장소를 나타낼 수 있습니다.
- 짧은 기간에 걸친 지표의 급격한 변화는 검토가 필요한 장소를 나타낼 수 있습니다.
그러나 나는 그 자체로 항상 ‘좋은’또는 ‘나쁜’코드를 나타내는 단일 메트릭을 생각할 수 없습니다. 측정으로 볼 수없는 것에 대한 예외와 이유가 항상 있습니다.
내가 간과 한 코드 메트릭에서 얻을 수있는 마법 같은 통찰력이 있습니까? 게으른 프로그래머 / 관리자는 코드를 읽지 않을 변명을 찾고 있습니까? 사람들이 거대한 레거시 코드 기반을 제시하고 시작할 곳을 찾고 있습니까? 무슨 일이야?
참고 : 특정 스레드에 대한 답변과 댓글 모두에 대해 이러한 질문 중 일부를 요청했지만 답변이 없었기 때문에 뭔가 빠졌을 수 있으므로 일반적으로 커뮤니티에 질문해야한다고 생각했습니다. 메트릭 배치 작업을 실행하고 실제로 다른 사람의 코드 (또는 내 자신의 코드)를 다시 읽을 필요가없는 것이 좋을 것입니다. 실용적이지 않다고 생각합니다!
편집 : 논의되는 모든 메트릭은 아니지만 대부분의 메트릭에 대해 잘 알고 있습니다. 단순히 또는 임의의 품질 표준으로 볼 수는 없습니다.
답변
이 스레드의 답변은 다음과 같이 다소 이상합니다.
- “팀”, “유일한 수혜자”처럼 말한 메트릭스;
- “메트릭”은 그 자체로 의미가있는 것처럼.
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 개 이상의 라인 메서드, 높은 복잡성, 아마도 나쁠 것임). 그래도 나는 이것을 구입 한 장소에 가본 적이 없습니다.
