소스 코드에 유용한 지표는 무엇입니까? [닫은]

소스 코드를 캡처하는 데 유용한 지표는 무엇입니까?

예를 들어 (Executable?) Code of Code 또는 Cyclomatic Complexity 와 같은 메트릭 이 품질 보증에 어떻게 도움이되거나 소프트웨어 개발 프로세스에서 일반적으로 어떤 이점이 있습니까?

"코드 라인으로 소프트웨어 생산성을 측정하는 것은 비행기의 무게를 측정하여 비행기의 진행 상황을 측정하는 것과 같습니다."-Bill Gates

주제에 관한 Jeff의 게시물을 살펴보십시오.

지표 메이드 방문

소프트웨어 엔지니어링 : 죽었습니까?

소프트웨어 메트릭과 밀접한 관련이있는 Joel의 오래된 게시물이 있지만 Econ 101 관리 방법을 강력히 권장합니다.

나에게 중요한 점은 Jeff의 말이다. "책임의 책임있는 사용은 처음부터 수집하는 것만 큼 중요합니다."

코드 메트릭과 관련하여 나를 혼란스럽게 만드는 것은 더 이상 수행되지 않는다는 것입니다. 대부분의 회사는 직원, 공급 업체 및 시스템의 효율성에 대해보고하지만 아무도 코드를보고하지 않는 것 같습니다. 더 많은 코드 줄이 책임이지만 코드가하는 일이 더 중요하다는 답변에 동의합니다.

코드 라인 : '앞서 언급했듯이 이것은 중요한 측정이며 가장 진지하게 각 레벨에서 취해야합니다. 함수, 클래스, 파일 및 인터페이스는 장기적으로 유지 관리하기 어렵고 비용이 많이 드는 모든 코드를 나타낼 수 있습니다. 전체 코드 줄과 시스템이하는 일을 비교하는 것은 매우 어렵습니다. 많은 일을하는 것이 될 수 있으며이 경우 많은 코드 줄이있을 것입니다!

복잡성 : 이 측정은 아직 작업하지 않은 코드 기반에서 수행하는 것이 좋으며 문제 영역이 어디에 있는지를 잘 보여줄 수 있습니다. 유용한 일화로서 나는 자신의 코드 기반 중 하나에서 복잡성을 측정했으며, 가장 복잡한 영역은 변경해야 할 때 가장 많은 시간을 소비했던 영역이었습니다. 복잡성을 줄이기 위해 노력한 결과 유지 보수 시간이 크게 단축되었습니다. 경영진이 이러한 측정을 수행하면 시스템의 특정 영역에 대한 리팩토링 반복 또는 재 설계를 계획 할 수 있습니다.

코드 복제 : 이것은 내가 생각하는 한 매우 중요한 측정입니다. 코드 복제는 매우 나쁜 신호이며 시스템 설계 수준이 낮거나 복사 붙여 넣기를 수행하는 개발자에게 심각한 문제가 발생할 수 있으며 장기적으로 막대한 문제가 발생하고 유지 관리 할 수없는 시스템이 발생할 수 있습니다.

종속성 그래프 나쁜 종속성과 순환 종속성을 찾는 것은 코드에서 중요한 측정입니다. 이것은 거의 항상 수정이 필요한 잘못된 고급 설계를 나타냅니다. 누군가가 전자 우편 라이브러리 내부에서 addNumber를 사용하여 재무 계산을 수행하기 때문에 하나의 종속성이 불필요한 다른 많은 것들을 빨아 들일 수 있습니다. 전자 메일 라이브러리가 변경되고 재정이 중단되면 모든 사람이 충격을받습니다. 모든 것이 한 가지에 의존하는 경우 유지 관리하기 어렵고 잘못 설계된 모든 라이브러리를 가리킬 수도 있습니다.

좋은 측정은 항상 시스템의 모든 기능이 작은 설치 공간을 가지고 있음을 알려줍니다. 종속성, 복잡성, 중복이 줄어 듭니다. 이것은 느슨한 결합과 높은 응집력을 나타냅니다.

이 "소스 코드 메트릭스"쓰레기도 죽지 않습니까?

원시 소스 코드 라인 (SLOC)은 가장 오래되고 가장 쉽고 가장 기본적인 메트릭입니다.

Halstead는 원래 전체 메트릭을 제안했습니다. 많은 스포일 스포츠가 명백한 연구를 할 때까지 많은 사람들이 재미있는 쓰기 측정 프로그램을 가지고 있었고, 각각의 모든 Halstead 메트릭이 SLOC와 직접적으로 밀접한 상관 관계가 있음을 보여주었습니다.

이 시점에서 SLOC는 항상 측정하기 쉽기 때문에 Halstead의 지표는 포기되었습니다.

품질 보증을위한 소스 코드 메트릭스는 두 가지 목표를 목표로합니다.

• 버그가 적은 코드 작성
• 손쉬운 유지 보수를위한 코드 작성

둘 다 가능한 한 간단하게 코드를 작성합니다. 이것은 다음을 의미합니다.

• 짧은 코드 단위 (함수, 메소드)
• 각 단위의 몇 가지 요소 (인수, 지역 변수, 명령문, 경로)
• 기타 여러 기준이 다소 복잡합니다 ( Wikipedia의 소프트웨어 메트릭 참조 ).

내가 아는 한, 발견 된 버그 수는 코드 라인 (아마도 이탈), 모듈로 언어, 프로그래머 및 도메인과 직접적으로 관련됩니다.

나는 버그와 상관 관계가있는 다른 간단하고 실용적인 메트릭을 모른다.

내가하고 싶은 한 가지는 내가 다루고있는 다른 프로젝트에 대한 숫자를 실행하기 시작하는 것입니다-Test Coverage :: kLOC, 그리고 "인지 품질"에 대해 논의하여 상관 관계가 있는지 확인하십시오.

측정 항목은 답변을 통해 수행 할 작업을 알고있는 경우에만 유용합니다. 본질적으로 소프트웨어 메트릭은 온도계와 같습니다. 98.6 ° F에서 무언가를 측정한다는 것은 정상적인 온도가 무엇인지 알 때까지는 아무 의미가 없습니다 . 위의 온도는 체온에는 좋지만 아이스크림에는 좋지 않습니다.

유용 할 수 있는 일반적인 측정 항목 은 다음과 같습니다.

• 발견 된 버그 / 주
• 버그 해결 / 주
• # 요구 사항 정의 / 릴리스
• # 요구 사항 구현 / 릴리스

처음 두 측정 경향. 고칠 수있는 것보다 더 빠른 버그를 찾으십니까? 두 가지 가능한 결과 : 버그를 수정하는 데 더 많은 리소스가 필요할 수 있으며, 따라 잡을 때까지 새로운 기능 구현을 중단해야 할 수도 있습니다. 두 번째는 당신이 얼마나 가까이 있는지를 보여줍니다. 애자일 팀은이를 "번 다운"차트라고합니다.

순환 복잡성 은 흥미로운 지표입니다. 기본 개념에서 함수 / 메소드의 고유 한 실행 경로 수입니다. 단위 테스트가 많은 환경에서 이는 모든 실행 경로를 확인하는 데 필요한 테스트 수에 해당합니다. 그럼에도 불구하고 Cyclomatic Complexity가 96 인 방법이 있다고해서 반드시 버그가있는 것은 아니며 합리적인 신뢰를 제공하기 위해 96 개의 테스트를 작성해야합니다. WPF 또는 파서 생성기를 통해 생성 된 코드가이 복잡한 것을 만드는 것은 드문 일이 아닙니다. 메소드 디버깅에 필요한 노력 수준에 대한 대략적인 아이디어를 제공 할 수 있습니다.

결론

측정 할 때마다 다음을 정의해야하거나 쓸모가 없습니다.

• "정상"이 무엇인지 이해합니다. 이것은 프로젝트 수명 동안 조정될 수 있습니다.
• 일종의 조치가 필요한 "정상"이외의 임계 값입니다.
• 임계 값을 초과 할 때 코드를 처리하기위한 계획입니다.

측정 항목은 프로젝트마다 다를 수 있습니다. 전체 프로젝트를 사용하는 몇 가지 메트릭이있을 수 있지만 "정상"의 정의는 다릅니다. 예를 들어, 한 프로젝트가 주당 평균 5 개의 버그를 발견하고 새 프로젝트가 주당 10 개의 버그를 발견한다고해서 반드시 무언가가 잘못된 것은 아닙니다. 이번에는 테스트 팀이 더 세심한 것일 수 있습니다. 또한 "정상"의 정의는 프로젝트 수명 기간 동안 변경 될 수 있습니다.

미터법은 온도계 일 뿐이며, 온도계로하는 일은 여러분에게 달려 있습니다.

소스 코드는 자산이 아니라 책임입니다. 이를 염두에두고 코드 라인을 측정하는 것은 집을 짓는 동안 지출 한 달러를 추적하는 것과 유사합니다. 예산을 유지하고 싶다면 반드시 수행해야하지만, 하루에 $ 1000를 쓰는 것이 하루에 $ 50를 쓰는 것보다 낫다고 생각할 필요는 없습니다. 그 돈을 위해 얼마나 많은 집을 지 었는지 알고 싶을 것입니다. 소프트웨어 프로젝트의 코드 줄과 동일합니다.

간단히 말해서 소스 코드 자체를 측정하는 것은 유용하지 않기 때문에 소스 코드에 대한 유용한 지표가 없습니다.

소스 코드는 단순히 시퀀스, 선택 및 반복의 조합이기 때문입니다. 우리가 합리적으로 기대할 수있는 가장 최적의 소프트웨어를 설명한다면 다음과 같습니다. 작업을 수행하는 데 필요한 최소한의 코드 줄을 사용하여 거의 100 % 테스트 코드 적용 범위를 가진 소프트웨어이지만 변경에 견딜 수있을만큼 유연합니다.

KLOC 카운트가 성능을 측정하는 데 쓸모없고 심지어 유해한 이유를 보여주는 일화입니다.

몇 년 전에 저는 KLOC 수를 팀과 개인의 유일한 성과 척도로 사용하는 대규모 프로젝트 (회사에서 70 명 이상, 고객에서 30 명 이상)를 작업했습니다.

우리의 Y2K 노력을 위해 (얼마나 오래 전인지 알려줍니다) 우리는 우리 팀이 담당 한 코드 섹션을 크게 정리했습니다. 우리는 약 30.000 줄의 코드를 작성하여 5 명의 사람들에게 3 개월의 나쁜 작업이 아닌 릴리스로 끝났습니다. 우리는 또한 70.000 줄의 코드를 긁어 냈습니다. 특히 새로운 코드와 결합 된 3 개월 동안 매우 훌륭했습니다.

분기의 최종 결과 : -40.000 코드 라인. 분기 별 실적 검토 기간 동안 회사는 분기당 20.000 라인의 생산성 요구 사항을 충족하지 못하여 회사의 공식적인 견책을 받았습니다 (결국 툴은 40.000 라인의 코드를 생성했음을 보여주었습니다). 프로젝트 관리자와 품질 보증팀이 개입하지 않고 징계를 전복하고 칭찬으로 대체하지 않은 경우, 우리 모두는 판촉, 교육, 임금 인상 등을 위해 성과가 저조하고 우회 된 것으로 등재되었습니다.

몇 달 후 (시간이 오래 걸리는) 회사는 생산성 기준을 검토하고 기능 팀 분석을 기반으로 새로운 시스템을 만들기 위해 전문가 팀을 고용했다고 들었습니다.

아직 아무도 언급하지 않은 단위 테스트 진술 / 결정 범위 (단위 테스트에 의해 실행되는 코드의 백분율)에 놀랐습니다.

코드 적용 범위는 애플리케이션의 몇 퍼센트가 재앙 적으로 실패하지 않는지 알고 있다는 점에서 유용합니다. 나머지 유용성은 단위 테스트의 품질에 달려 있습니다.

커밋이 작을수록 일반적으로 더 좋습니다. 이것은 코드 당이 아니라 SCM 도구에 관한 것이지만 매우 측정 가능한 지표입니다. 커밋이 작을수록 각 변경 사항을 원자 단위로 쉽게 볼 수 있습니다. 특정 변경 사항을 되돌리고 문제가 발생한 시점을 정확히 파악하는 것이 더 쉽습니다.

커밋이 빌드를 중단하지 않는 한 ...

이것들은 진행 측면에서 매우 유용한 절대 메트릭은 아니지만 코드 상태에 대한 일반적인 아이디어를 제공하는 데 사용될 수 있습니다.

특히 Cyclomatic Complexity 주어진 코드 기반이 모듈화되는 방식을 시각화하는 데 유용한 것으로 나타났습니다. 모듈 당 소스 수가 적고 많은 모듈이 있음을 의미하므로 일반적으로 복잡성이 낮습니다.

나는 종종 거대한 C ++ 패키지로 작업하고 Cyclomatic Complexity 또는 끔찍한 FanIn / FanOut을 리팩토링 할 가치가있는 문제가있는 코드를 찾을 때 일반적으로 꽤 좋은 붉은 깃발입니다. 문제를 해결하면 일반적으로 전체 코드베이스가 향상됩니다.

물론이 숫자는 볼 가치가있는 것에 대한 힌트 일뿐입니다. 빌드를 실패하거나 커밋을 거부하는 데 어려움을 겪는 것은 어리석은 일입니다.

코드 메트릭을 사용하는 작업에는 여러 가지 상황이 있습니다.

코드를 작성하는 동안

내 일상 업무에서 가장 크고 아마도 가장 중요한 용도는 Checkstyle에서 , 우리가 정의한 규칙 세트에 대해 내 코드의 메트릭을 (다른 것들 중에서) 지속적으로 확인하고 내 코드가 그렇지 않은 장소에 플래그를 지정하는 Java 개발자를위한 도구입니다 그 규칙을 준수하십시오. 코드를 개발할 때 내 방법이 길어 지거나 복잡해 지거나 결합되면 실시간으로 알려주므로 단계적으로 뒤로 물러나서 리팩토링에 대해 더 나은 것으로 생각할 수 있습니다.

개발자는 모든 상황에 적용되지 않으므로 모든 규칙을 위반할 수 있습니다. "규칙"은 생각을 자극하고 "이것이 최선의 방법입니까?"

품질 관리 / 코드 검토 중

일반적으로 코드 검토를 수행 할 때 가장 먼저 수행하는 작업은 검토중인 코드의 코드 적용 범위를 코드 적용 도구와 함께 확인하여 코드 행을 강조 표시하는 것입니다. 이것은 테스트 코드가 얼마나 철저한 지에 대한 일반적인 아이디어를 제공합니다. 중요한 코드가 제대로 테스트되는 한 적용 범위가 20 % 또는 100 %인지는 중요하지 않습니다. 따라서 적용되는 백분율은 다소 의미가 없지만 0 %는 내가주의 깊게보고 싶은 것 같은 아픈 엄지 손가락처럼 보입니다.

또한 팀이 동의 한 메트릭이 '있는'경우 (있는 경우) 개발자와 의견이 일치하는지 또는 개선 방법을 제안 할 수 있는지 확인합니다. 새로운 코드를 작성하기 위해 팀에서 이러한 개발 지표를 합의하면 코드를 개선하는 데 큰 도움이됩니다. 우리는 훨씬 적은 모 놀리 식 방법을 작성하고 단일 책임 원칙 에서 훨씬 우수합니다 .

레거시 코드의 추세 개선 개선하려는 레거시 코드 가 많이 있습니다. 어느 시점에서나 메트릭은 매우 쓸모가 없지만, 우리에게 중요한 것은 시간이 지남에 따라 코드 범위가 커지고 복잡성 및 커플 링과 같은 것들이 다운된다는 것입니다. 따라서 메트릭이 Continuous Integration 서버에 연결되어 시간이 지남에 따라 올바른 경로를 유지할 수 있습니다.

새로운 코드 기반을 파악하기 내가 익숙하지 않은 코드 기반을 살펴볼 때만 소스 코드 메트릭 라인을 사용할 수있는 유일한 시간은 정보입니다. 작업 한 다른 프로젝트에 비해 프로젝트의 대략적인 크기를 신속하게 측정 할 수 있습니다. 다른 메트릭스를 사용하면 프로젝트 품질에 대한 대략적인 아이디어를 얻을 수 있습니다.

중요한 것은 통계를 추세, 토론 또는 앞으로 나아갈 수있는 출발점으로 사용하고 정확한 수치로 종교적으로 관리하지 않는 것입니다. 그러나 올바르게 사용하면 올바른 코드를 개선하는 데 도움이 될 수 있다고 생각합니다.

Q : 소스 코드를 캡처하는 데 유용한 지표는 무엇입니까?

사업용:

A : 근무 시간

코더의 감독자 :

A : 상관 없습니다. 오늘 모든 것을 해보자

코더의 자부심 :

A : SLOC 수 (소스 코드 라인)

코더의 어머니 :

A :이 부드러운 프렌치 롤을 더 먹고 차를 마신다

아래 의견에 계속 ...

기억하십시오 : 모든 코드는 최소한 하나의 명령으로 줄일 수 있습니다. 모든 코드에는 하나 이상의 버그가 있습니다. 따라서 모든 코드를 작동하지 않는 단일 명령으로 줄일 수 있습니다. 희망이 도움이됩니다!